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In this Issue 

The 1990s may be remembered as the decade when multimedia capability 
became commonplace in computer technology, communications, and enter- 
tainment The exact meaning of multimedia depends on who's using the word. 
On HP engineering workstations (HP 9000 Series 700 and 800 computers), one 
meaning of multimedia is HP MPower, a collection of multimedia hardware and 
software tools and applications that allow users to create, manipulate, and 
share textual information and nontextual information such as audio, image, 
graphics, and video data over a network. 

As described in the article on page 10, on an HP MPower-eguipped workstation 
the following services are available to the user: faxing, online documentation, 
scanning, image viewing, audio recording and playback, video in a window, window capture, whiteboard 
collaboration, real-time application sharing, and color graphics and PostScript™ printing. The development 
of HP MPower has been an evolutionary process, with new capabilities being developed as user needs 
changed and new technologies became available, and the product continues to evolve. The article on 
page B tetls the story of this evolution and goes on to describe two very recently released HP MPower 
capabilities: digital video, or full-motion video with synchronized audio, and telephone functionality with 
a new HP MPower telephony component, HP TeleShsre, These last two media types were added to HP 
MPower too late for articles on them to be prepared in time for this issue. We hope to include articles on 
their design in a future issue. 

HP MPower, its various components, and its client/server architecture are introduced in the article on 
page 10, HP MPower's graphical user interface is the HP Visual User Environment HP VUE. It's the subject 
of the article on page 20. The application sharing component of HP MPower is HP SharedX (page 23), a 
communication tool that extends the industry-standard X Window System so that two or more users at 
different workstations can share and interact with the same X-protocol-based applications almost as if 
they were at the same workstation. Existing X applications don't have to be changed to be shared with 
HP SharedX. Implementing this new application sharing technology in a heterogeneous computing envi- 
ronment, the designers discovered, poses many difficult design challenges, some of which don't have 
perfect solutions. A component of HP SharedX called Whiteboard (page 28) allows users to share a 
snapshot of a portion of a display and to annotate that snapshot. 

Image files contain computer graphics and digital records of physical objects such as photographs, 
pages from books, and faxes. The HP Image Library (see page 37) contains image manipulation tools, 
compression and decompression functions, picture quality adjustment functions, and support for indus- 
try standards. Its functionality is used by several HP MPower components. For environments in which 
users have a multitude of printers to choose from, HP SharedPrint (page 44} provides a simple graphical 
interface that enables users to select a target printer and a set of options without many of the typical 
problems, The HP MPower fax utility (page 53) provides automatic dialing, transmission, and delivery of 
facsimile documents from a workstation. 

HP MPower provides the hardware and software for recording and playing audio files over a network, 
incorporating audio in email, adding audio annotations to system files, and recording and playback using 
external devices such as tape recorders, CO players, and VCRs. HP MPower's audio functionality, appli- 
cation development toofs, and hardware and software audio architecture are described in the article on 
page 62. Video technology in HP MPower is provided by a hardware/software component called HP 
VideoLive (page 68). It provides full-motion video in a movahle, scalable window and works with existing 
HP graphics subsystems without degrading system or graphics performance. 
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HP MPower also provides a multimedia email, or electronic mail facility (see page 71). The well- 
established processes of creating, sending, receiving, printing, and replying to email messages are 
maintained and applied to messages containing multimedia objects such as image and audio files, 

Nearly 2000 online help topics are shipped with HP M Power. The HP online help system used by HP 
MPawer and other HP applications is described in the article on page 79, On page 90, one of the designers 
of the HP help system advises application developers on the issues they may encounter in providing 
online help for their applications. 

R.P. Dolan 
Editor 



Cover 

A workstation screen showing the HP MPower media panel and the HP MPower applications Image- 
View, which provides capabilities for manipulating and viewing different types of images, MailEditor for 
creating multimedia email, and Whiteboard, which enables two or more users to collaborate on the 
same image from different workstations. 



What's Ahead 

Coming next are design articles on the HP 9000 Model T500 corporate business server and the SoftBench 
Message Connector. There will also be technical articles on the use of fuzzy logic to assign printed circuit 
assemblies to production machines and on cleanroom software. 
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Development of a Multimedia Product 
for HP Workstations 

Providing multimedia capability on HP's workstations was an evolutionary 
process that was paced according to customer needs and the availability 
of quality multimedia hardware and software technology and low-cost 
workstations. 

by Gary R Rose, Jeffery T. Oesterle, Joseph E. Kasper, and Robert J. Hammond 



Multimedia technology was a burgeoning market when HP's 
Workstation Group first looked ai il in 1990. A lot of promise 
and exaggerated claims surrounded multimedia technology 
at; the time. The question was how IIP workstations could 
create a competitive advantage with the technology, The an- 
swer to this question resulted in HP MPower, a collection of 
multimedia tools and applications which are described in the 
articles in this issue beginning with an overview on page 10. 

This paper will describe the development history of IIP 
MPower and how it tamed HP workstations from simply 
computational tools into media-rich information access and 
communication channels for business and industrial users. 

The Start 

Looking at the marketplace hack in 1990 there were a num- 
ber of application areas in which multimedia technology was 
being applied. Persona! computers were being upgraded 
with CD-ROMs and sound cards, and typical multimedia 
application areas included presentations, computer-based 
training, and games. Workstations have difficulty competing 
with low-priced PCs for these markets. Since integrated 
networking capability was an advantage that workstations 
had over PCs at that time, we looked for markets that had 
distributed media requirements. We focused on two applica- 
tion segments: multimedia information management and 
real-time communication. The informal ion-management 
market included document image management, work flow, 
and corporate training. The real-time communication mar- 
ket included workspace sharing, multimedia email, confer- 
ence management, networked fax p telephone integration, 
and video teleconferencing. 

We visited our customers to learn about challenges facing 
their businesses so that we could determine where we could 
offer solutions. A common theme we heard was that, these 
companies needed to be more productive without signifi- 
cant increases in personnel They were global companies 
that needed to align their teams on common objectives, and 
get them working together. Increasingly, they relied on dis- 
iritmTed teams, alliances, and experts outside their com- 
pany. The need for communication among these teams was 
critical to their success. 

Communication between humans is more effective when it 
is natural. Media types such as recorded voice, pictures, and 
movies can add in formation to the communication that goes 



far beyond what traditional text can achieve. Facial expres- 
sions, body language, and tone of voice add cues to the 
meaning of the message. These cues help convey trust and 
understanding of what is being communicated. Multimedia 
computers can go far beyond traditional email in helping to 
facilitate communication, resulting in faster exchange and 
absorption of ideas. However, computer-assisted communi- 
cation tools have to be easy to use and a natural part of the 
environment for them to be adopted by large numbers of 
people. 

Although we wished that everyone owned an HP workstation, 
our customers did not have homogeneous IIP environments. 
If the technologies we provided did not work with their exist- 
ing equipment, then it would be difficult for them to deploy 
our products within their enterprises. Additionally, the im- 
portance of standards is very high in communication since 
they ensure that no one is excluded from a conversation 
because of the type of equipment they have. 

We had three clear challenges for bringing multimedia to 
corporate offices. First, we had to deal with the limited net- 
working capabilities of most existing environments* Second, 
the technology needed to be pervasive for people to use it. 
Finally, the technology needed to be very low-cost to be 
affordable for deployment within the enterprise. 

End users were pulling the application developers into the 
multimedia arena Thus, we needed to create desktop tools 
so users could immediately take advantage of multiple types 
of media without wailing for the applications to be devel- 
oped. These tools also had to include examples of how to 
use the progranuuing interfaces to the multimedia services 
so that, application developers could immediately provide 
multimedia capability in their applications. 

We wanted to leverage as much as possible the expertise 
within HP so we contacted numerous HP organizations. A 
PC-based collaborative multimedia project from HP Labora- 
tories in Pine wood and Bristol, England was one of the 
pieces of research that helped guide us. Engineers in Bristol 
demonstrated that for distributed work groups trying to 
solve a range of tasks* a shared drawing space that allows 
multiple users to annotate a picture was very effective in 
improving productivity. Audio communication was consid- 
ered the second most productive tool among these work 
groups. Surprisingly, seeing a video of the person they were 
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working with didiu improve productivity measurably. How- 
ever, it is interesting rhai they perceived they were more 
productive when using video to show the object hi 
discussed. 

Our customer feedback was that although they all wanted to 
be able to do video conferencing from their desks, they did 
not have the network mfrasiructure in place. Also, when 
asked which media they would incorporate in their trai: 
and documentation, the answers were overwhelmingly in 
favor of images and audio. We felt that it was important to 
stage technologies for customer acceptance, and build up 
the capabilities over time. We decided to defer distribui 
digital video support until customers became comfortable 
with digital media over networks and implementations were 
eost-efTeetive- 

To keep the incremental costs for multimedia down we tried 
to implement as much as possible in software running on a 
PA-RISC CPU, This also allowed us to adapt * m systems 
easily to new algorithms and standards, to provide access to 
our installed base, and to take advantage of new processor 
improvements. 

1991— The Base Platform 

Our customer feedback implied that the first technologic 
be integrated should be image and audio. We asked custom- 
ers about their imaging needs and found thai while comput- 
ers could display images, users typically had to run them 
through several conversion steps before their display pro- 
gram could put the image on the screen. Among graphics 
products there was a wide range of image formats and frame 
buffer pixel depths. This made image display inconsistent 
from machine to machine. Another problem was that the 
screen would turn funny colors when more than one image 
was displayed at a time because of the lack of color map 
sharing. 

We addressed these problems wilii an image library and 
tried to make images as easy to use as text and grapliics. We 
integrated image and audio libraries into the IIP-UX f operat- 
ing system so that applications would have an installed base 
for their functionality. There were no standards available for 
programming interfaces, so we modeled the interfaces to feci 
like X windows, which is a paradigm familiar to our applica- 
tion developers. Rather than creating HP file formats, com- 
mon formats from the PC and Apple Macintosh worlds were 
used and conversion services were provided to import and 
export data from these platforms. We used algorithm exper- 
tise from HP Laboratories and the CPU power of our systems 
to include compression and decompression of images using 
ihe JPEG (Joint Photographic Expert Group) standard, 
which allows images to be useful on low-end machines with 
small disks. The image library was designed as an extensible 
pipeline architecture that would allow applications to add 
new file types or special operations. 

( hir approach to audio support was to integrate audio on the 
motherboard of our workstations. Instead of taking the tradi- 
tional approach of providing a DSP (digital signal processor) 
for moving the audio I o the CODEC (coder/decoder), we use 
the main processor. This not only saves the cost of the DSP 
but also the dedicated memory for the DSP and other support 
logic. The PA-RISC processor is much faster than commercial 



5, and it allows more complex functions to be applied to 
media streams. 

We felt it was important to develop small applications such 
as an audio editor that would provide end user tools so 
there would be market demand for the technologies. We also 
gave away the source code for these small applications so 
that developers would have working examples to start with 
when they developed their own applications. 

The audio and image library were packaged with our X 

window sharing product HP SharedX. making up our first 
multimedia offering. The audio library, the image library, 
and HP Shared. X are described on pages 62, 37, and 23 
respectively, 

1992— Media I/O 

In l! " (1 to make our existing technologies more 

useful and postponed digital video. We fell we could bring 
our customers more value by leveraging the strengths HP 
had in computer products and integrating those products 
with the base tools. We ported The HP ScanJet lie from 
Microsoft * 3 Windows to the X Window System to provide a 
way to gel images into the workstation. We created a prodm-t 
called HP Shared Print to allow a multitude of image formate 

[ ninted on the wide range of PCL and PostScript ,M 
printers available. We added fax technology' so that users 
could have another way to communicate with images. This 
w r ould also allow communication with people outside their 
normal networking environment We collar) orated with third- 
party vendors to provide hardware for video in a window 
and to allow nsers to Capture digitized frames from the 
video, HP SharedPrint, HP MPower fax, and our first video 
offering are described on pages 44, 53, and 68 respectively. 

We upgraded ihe audio thai is built onto the CPU board GO 
CD quality to anticipate low-cost speech recognition, text-to- 
speech capability, and computer-based training. The HP-UX 
elm mailer was integrated with the new media data types to 
handle 4 compound document mail messages using the inter- 
mi standard MIMIC (Multipurpose internet Mail Exten- 
sions). To improve the usability of the system we did exten- 
sive up-fronl i ask analysis, We determined how ihe tools 
would be used to accomplish different tasks and worked to 
eliminate ihe number of steps users needed to succeed ,n 
those tasks. We made the use* interfaces appear more com 
sistent among the different tools* We used HP SharedX to 
replicate our graphical user interfaces and solicited feed 
back from the different HP organizations developing compo- 
nents for IIP MPower and EBP VI E \ Visual User Environ- 
ment) 2-0 customers. The HP VUE team worked closely with 
us lo integrate the media and collaborative tools into the 
control panel of the IIP VUE 3*0 control panel. We delivered 
this collaborate user environment to the market under Che 
name HP MPower LO. 

HP Vl'E 3.0 and the new elm editor are described on pages 
20 and 71 respectively. 

1993— Ready for Video 

In 1993 we improved IIP MPower in three dimensions by 
adding digital video, integrating telephony, and dram at.icaUy 
improving ihe flexibility for configuring the client/server 
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environment so that fax and print servers can reside on 
different machines. These features became HP MPower 2.0. 

Digital \Ideo in HP MPower 

Recent advances in rompuliT-processing speed and video- 
compression techniques have made it possible to combine 
full-motion video and synchronized audio into a form of 
computer data. This data, known as digital video, can be 
delivered over standard computer a$S$ telecommunication 
networks and can be integrated into multimedia applications 
such as computer-based training programs. 

In the computer-based training market, there is typically a 
small number Of authors and a large number of people who 
use this form of training. Our goal was to deliver cost- 
effective digital video playback for desktop computer-based 
training. We worked with HP Laboratories and t he HP 9000 
Model 712 team to integrate the video playback algorithms 
< ighi ly into the PA-RISC 7100LC chip. The graphics team 
provided new blithering (dithering and visual blending) algo- 
rithms and media-oriented frame buffer access modes that 
greatly assist in the rendering perfomiaji.ee, giving the ap- 
pearance of a 24-l)i t svsihii with the cost of an 8-bit system. 

Standards- Based File Format. HP's digital video implementa- 
tion supports the MPEG-1 (Moving Pictures Expert Group) 
file format. MPEG4 is an internationally recognized stan- 
dard for compressing synchronized audio and video data. 



MPEG-1 maintains a high-quality image (comparable to VHS 
tape) while supporting compression ratios up to 200:1. 

Key Benefits. HP MPower users can play MPEG-1 movies on 
any HP 9(X)0 Series 700 workstation without additional hard- 
ware. The new HP 8006 Model 712 workstation provides 
exceptional price/performance value for playing video be- 
cause ot instruction set enhancements to the Model 712's 
PA-RISC chip and enhancements to the graphics subsystem. 

Since MPEG-1 movies are a form of digital data they can be 
transferred to other users via email or standard HP-CX 
commands such as ftp or uucp. 

Digital Video Components, HP MPower 2,0 has two digital video 
software components: the video player ami the video con- 
verter, The \ideo player software plays MPEG-1 movie files 
with or without audio (see Fig. 1). The user can adjust the 
size of the window and anjust the audio and video qualities. 
Any frame in the video can be examined, and play forward 
or reverse capabilities are also available. Video frames can 
be captured and saved as TIFF, JFIF, Xbm, or Xwd images. 
Images can also be printed directly from the application, 

The video conversion utility con veils JPEG movie files to 
MPEG-1 format. JPEG (Joint Photographic Expert Group) is 
an internationally recognized standard that deals with the 
compression of still images. 



Video Player — conan:/users/video/hp1,mpg 
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Fig. 1. The digital video player 
playing an MPEG-1 movie file. 
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MPEG-1 mo\ies can be obtained by capturing video data 
from an external source such as a video camera and storing 
it in JPEG movie fiies.t The JPEG files can then be con- 
verted to MPEG-1 format with the video conversion utility. 
Alternatively, customers can use a service bureau to convert 
their video material to MPEG-1 format. 

Telephony 

The integration of telephone functionality on a workstation 
provides users with a powerful communication tool that 
enhances the use of both the telephone and the computer 
The telephone becomes easier to use because the computer 
can take care of the details of telephone use such as special 
function buttons, volume control finding and dialing phone 
numbers, and tracking telephone use. The computer be- 
comes a more effective communication and collaboration 
took Also t with telephone access, users can send faxes from 
their desktop, share their computer audio over the tele- 
phone, and get caller information fr< im a database based on 
the caller identifier (e.g., telephone number). 

HP's telephony product, or HP TeleShare, provides a two- 
line telephony card for HP's 9000 Model 712 workstation. 
The HP TeleShare card is an optional daughter card, with 
two complete analog! t telephone line interfaces. Each tele- 
phone line has a digital signal processor to provide data and 
fax modem support and to handle audio mixing for voice 
mode use. Having two telephone Lines provides the capabil- 
ity to place a telephone call using one line while setting up a 
data or fax connection on the other line. 

HP TeleShare also includes a telephone application that pro- 
vides users with access to various telephone functions from 
their workstations. For switching the mode of each telephone 
line between data modem, fe modem, and voice there is a 
small control applical i< >n 1 fiat, controls the mode of each HP 
TeleShare line and reflects any changes in mode to flic user. 
Fax functionality i d through a single-user configura- 

tion of the IIP MPowcr fax facility, while data modem func- 
tionality can be accessed through the users favorite data 
communications package such as kermit or cu, provided they 
are configured to use the HI 5 TeleShare card as a modem. 

HP TeleShare has direct access CO the HP MPower audio 
subsystem on the workstation, which is what makes it pos- 
sible for a workstation with die audio headset to be used as 
a full-function telephone. This also makes it possible to 
share computer-generated audio over the telephone line and 
to record telephone conversalions into computer audio files 
for later reference. Because telephone audio is low-quality. 
HP TeleShare provides services to deal with quality levels. 
The audio server automatically res&mples the computer 

T A third-party video card must be used to capture JPP" i i • 
t r Analog telephone line refers to the traditional. Plain -Old -Telephone-System [POTS! Telephone 

tines, as opposed la ISDN (imeoiated-ser vices digital network) m ISDN- J ike proprietary 

digital telephnnosvv ■ 



audio so that the user is not constrained by this restriction. 
This makes it possible to play CD^uaiity samples over the 
telephone line or to record from the telephone line into s 
CD-quality sample file. 

Applications. Two OSF/Motif applications are provided with 
IIP TeleShare. The first is called teleshare, which provides a 
paphical user interface to the telephone functions provided 
>duct. These functions include a telephone keypad , 
volume and hook controls, forwarding buttons, program- 
mable speed diai keys, and a display area for incoming call- 
er-identifier information. 

The second application, called telctrl, provides control and 
status information on the media modes (fax. data, voice) for 
the HP TeleShare telephone lines (described below). There 
is also a helpful graphical setup and configuration program 
to help the system administrator configure the HP TeleShare 
product properly 

Fax and Data Modem Lines. HP TeleShare can function as a 
fax or data modem in addition to serving as a full-function 
telephone. The telctrl application allows control of the cur- 
rent mode of each of the HP TeleShare telephone lines, as 
well as reflecting any changes in the mode, The mode can 
also be changed automatically when a modem application 
opens a connection to the port supplied for interfacing to 
IIP TcleShares modem functionality Only one line at a time 
can be used as a modem, but the other telephone line would 
be available for voice mode use. 

A single-user con figuration of the IIP MPower fax product 
is shipped with HP TeleShare to provide support: for fax 
functionality, 

Conclusion 

Enhancements or additions to the HP MPower product will 
be guided by our ability to leverage HP and externa] multi- 
media fcootei and technologies and integrate them into the 
product in reduce COSt and to take advantage ofIIP*s distrib- 
uted computing and object-oriented design expertise. We 
will continue to listen to our customers' needs and provide 
frameworks that will allow tighter integration of the parts to 
improve usability Our internal use of ih<- collaborative tools 
for our own communications with remote experts and h 
both inside and outside of HP will provide us wilh additional 
insight inh> rnminuniraiion needs for the future. 

HP-UX is based on and is compatible with UNI* Stfiem laboratories' UNIX* operating system 
It also complies with X/Opens* XPG3, POSIX 1Q03.1 and SVID2 interface specifications 
UNIX is a registered trademark of UNIX System Laboratories Inc in the U.5 A and other countries 

: : a trademark of tyOpen Company Limned in the UK and other countries. 
Microsoft is a US. registered trademark of Microsoft Corporation 
Windows is a U.S. trademark ol Microsoft Corporate 

PostScript ksa trademark of Adoba Systems Incorporated which may be registered in certain 
jurisdictions. 
OSF/Motif is a trademark of the Open Software foundation in ths U.S. and oBie* countries 
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HP MPower: A Collaborative 
Multimedia Environment 



Multimedia capability on a workstation enables users to interact with 
their applications and communicate with others in a variety of formats 
(textual and nontextual). HP MPower provides an environment in which 
users have easy access to the multimedia facilities at their workstations, 
and application developers can easily add new multimedia tools 

by William R. Yoder 



Imagine being able to have a project team meeting in which 
the participants are widely dispersed but are able to collabo- 
rate from their desktop workstations as tf they were all in 
the same room. To carry out such an electronic meeting, the 
participating workstations must provide the facilities thai 
allow users to create, manipulate, and share textual and 
nontextual information such as audio, image, and video data 
over a network. 

HP MPower provides workstation conferencing and the 
collaborative sharing capabilities mentioned above. Unlike 
video teleconferencing, which requires a significant hard- 
ware and networking investment, HP MPower is a low-cost 
sofl ware product that works with today's workstations and 
networks, HP MPower offers a full range < if mult i media types 
such as audio, image, graphics, video, and lext (Fig. 1 ), with 
five ways of sharing information: print, mail, fax^ whiteboard, 



and real-tit ne application sharing. HP MPower offers access 
to this set of multimedia tools through the HP VUE 3.0 
graphical user interface. 

IIP MPower is currently supported on the HP 9000 Series 
700 and 800 workstations and HP X stations. 

The Media-Equipped Knowledge Worker 

A typical knowledge worker uses a workstation to process 
information in the form of documents, spreadsheets, graph- 
ics presentations, and so on. In addition to these Rerns, the 
media-equipped knowledge worker has access to sound 
clips, video frames, scanned images, faxes, and other media 
objects, Whether among a local team or among colleagues 
who are scattered geographically, the media-equipped knowl- 
edge worker benefits by sharing high-fidelity information at 
a high bandwidth. 




Fig, 1. A typical HP MPower dis- 
play staring windows open for 
wliiiebuard, images, and video. 
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Media 



_-==L 



Send and Receive Faxes 



Scan Monochrome and Color images 



-* View Xwd. Xhm, TIFF, GIF, StartMS*, 

and JPEG Images 



Fig* 2. Multimedia mail composing. 

Workstations and PCs capable of providing multimedia 
access have until recently existed as Islands of technology, 
only good for standalone applications. A developer logs into 
such a workstation and creates, say, a training module that 
end users can access only at the isolated workstation. By 
combining the power of media technology with networked 
systems niniiing the HP-UX* operating system, HP MPower 
enables users to collaborate effectively via a workstation 
medium. 

For example, suppose Margaret wants to send her col- 
leagues a document consisting of text, a scanned image of a 
competitors magazine ad, and a voice clip commenting on 
the article. She presses the mail button on the IIP VUE front 
panel shown in Fig. I to compose the mail message shown 
in Fig. 2, presses the scanner button on her IIP MPower 
media panel to scan in the ad t and then presses I he audio 
button to record her comments, Kin ally, she drags and drops 
the scanned image and voice clip into tier mail message and 
sends it. on its way. 

As another example of using this media-equipped work- 
station, consider Jeffrey who wants to work on a CAD draw- 
tug with his colleagues in Colorado and Washington, From 
lln i HP VUE file manager, he drops the drawing inlo a white- 
board window on his workstation, calls his colleagues on 
the telephone, and uses the whiteboard window to interact 
and collaborate wjih Ins colleagues. The whiteboard and the 
software for sharing windows are discussed in (he article mi 

page 23, 

The IIP MPower System 

On a fully-equipped HP MPower-enabled workstation the 

Following services are available to the user 

• Faxing 

• Online Documentation 

• Scanning 

• Image Viewing 

• Audio Recording and Playback 

• Video-inn- Window 

• Window Capture 

• Whiteboard Collnix nation 

• Application Sharing 

I tolor Graphics and PostScript™ Priming. 

Many of the services listed above arc accessible from the 111 1 
MPower media panel shown in Fig. 3. Some of the 01 her HP 
MPower features accessible from ibe front panel include: 










'ffYiiiisuiiiirJ 



Play. Record, and Edit Audio 



View Video in a Window from a Variety of 
Video Sources and Capture Video frames 



Capture Window Contents 



Import. Share, and Annotate Images 



Share Application Windows 



Fig. 3. HP .MPower mediu panel 

• Audio control lor adjusting global audio output devices 

• Help control lor an essing system-wide online documentation 

• Print control tor printing text and graphics, managing print 
requests, and administering printers 

• Mail control for leading and composing plain text and media- 
embedded mail messages. 

Hardware Components. The basic HP MPower workstation 
consists of a high-resolution display, a keyboard, and a 
mouse. For a fully-equipped IIP MPower multimedia 
workstation The other hardware components include: 

• Huilidn tt-bii or H>bii audio with speaker or plug-in headset 

• External scanner with SCSI interface 

mat fax modem (or modems) wilh serial interface 
kisa based video cant 

• A variety of serial and parallel printers 

Software Components. HP MPower software consists of a 
number of lightly integrated media tools coupled to r In IIP 
VUE 3.0 user environment with Interprocess communication 
mechanisms for distributer! processing. HP VI "K 1 .1) and MP 
MPower are peers in the software hierarchy (see Fig. I \. 
When the user selects an IIP MPower media object ie.g., 
audio file) from the IIP TOE 3.G display, UV VUE hands i ■■■». 
no! over to IIP MPower to take the appropriate action on 
ihe object. 
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HP VUE 10 



OSF/Motif Widgets 



X Window System 



Operating System and Network Software 



Hardware Pfarlorm 



Fig. 4. The software hierardwial relationship between HP VUE 3.0 
arid HP MPower. HP VUE '10 provides user interf&ee and $&$$&p 
services for the look and style of HP MPower media objects, and 
HP M I *i m t provides tin- .v inn-, as$ ■• lafted with a particular media 
object. 

A typical media tool consists or an OSF/Motif-based client 
application, its run-time libraries, a backeml sen it process, 
and the appropriate device drivers (see Fig t 5). At lite lowest 
level, the device drivers control the hardware. For example, 
the VideoLive card uses an X-servcr extension to access the 
frame buffer. This X-server extension enables direct hard- 
ware access to the frame buffer, so that the VideoLive client 
can manipulate 24-bit 640-by-480-pixel images within the 
context of an 8-bit root window. Media server components 
are described in more detail biter in this article, and the 
VideoLive card is described in the article on page 68. 
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Fig. 5. The architec -ture for a distributed nvultimedia application. 



Important f IP MPower run-time libraries include the image 
and audio libraries, which are described in the articles on 
pages : *7 and 62, respectively. 

The User Interface 

From a user's point of view, the IIP MPower workstation 
consists of an integrated set of tools and their associated 
media objects, HP MPower provides facilities thai enable 
the user to: 

• Create media objects like a video frame sequence 

• Browse objects such as an incoming fax 

• Edit objects such as an audio track 

• Share objects such as a workstation window. 

The appearance and behavior of IIP MPower are derived 
from the OSF/Motif style guide and from the HP VUE 
desktop. For example: 

• Users can double-click to invoke actions, as in playing an 
audio file 

Users can drag and drop media objects on HP MPower 
tools, as in dragging and dropping an image file on the fax 
composer 

HP MPower tools are mouse-driven with pushbuttons, 
pull-down menus, and dialog boxes. 

The HP VUE 3.0 interface is described on page 20. 

Objects and Actions 

The file-typing mechanism used by HP VUE is extended to 
media objects. For example, PostScript files are denoted by 
a ps suffix appended to the base file name (e.g., Artide.ps). 
The HP MPower media tools such as the audio editor ensure 
that files are created with the appropriate suffix. 

Each media object has certain allowable actions or methods. 
For example, for audio Hies appropriate actions include Play, 
Edit, and Mail, and for image files appropriate actions include 
View, Print. Mail, and Fax. Table I lists I he objects and actions 
supported in HP MPower 1.0. These HP MPower actions 
extend the predefined IIP VUE 3.0 objects and actions. 

Online Documentation 

Extensive online documentation is provided with ihe HP 
MPower system. Built on the HP VUE 3.0 help system, HP 
MPower online documentation includes component level 
documental ion (e.g., help on the fax composer) and system 
level documentation (e.g., the "Welcome to HP MPower" 
chapter). 

Top level indexes provide users with easy access to all the 
help volumes on their system. The many hyperlinks! among 
topics allow users to browse hundreds of pages of task- 
oriented and reference material, which may or may not be 
related to the task they are performing. Another lype of help 
called item help enables users to find answers as they use the 
media tools in i lie context of the task they are performing. 

With the exception of a minimal set of introductory online 
documentation, ail help text is installed on die HP MPower 
server too unserve client disk space. More about IIP 
MPower help is covered in the articles on pages 79 and 90. 

t Hyoe» links ara navigation pointers to rented pieces of ml or Tat ion the online help article on 
page 3D provides more in formation about hyperf inks. 
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Table 1 




HP MPower Objects and Actions 


Object 


File 
Suffix 


Appropriate Actions in HP MPower 


SINFTLE 


3U 


Create, Edit, Mail, Play 


NEXTFILE 


snd 


Create, Edit. Mail. Play 


WAVTTLE 


,wav 


He, Edit, Mail, Play 


LI6FILE 


m 


Create. Edit. Mail. Play 


LSFILE 


18 


Create. Edit. Mail. Play 


L08FILE 


loB 


Create, Edit, Mail. Play 


ALFILE 


.a! 


Create, Edit, Mail, Play 


cfile 


,u 


Create, Edit, Mail Play 


PS 


,ps 


View. Prim, Mail Fax 


EPS 


eps 


View, Print, Mail, Fax 


TIFF 


.tif, .tiff 


View, Print. Create, Mail, Fax 


GIF 


# 


View, Print, Mail. Fax 


JPG 


-ipa- ipeg 


View, Print, Create, Mail, Fax 


BMP 


.bmf 


View; Print, Mail, Fax 


KM 


,xbm, .bm 


View, Print, Create, Edit, Mail, Fax 


PM 


.xpm, .pm 


View, Print, Create, Edit, Mail, Fax 


XWD 


xwd, .wd 


View, Print . Create, Mail Fax 


MIME 


mim 


View, Print, Create. Edit, Mail. Fax 


rnknown 


unk 


Create, Mail 


Data/Text 


Cany] 


View; Print, Create, Edit, Mail, Fax 



Client 



Client 



Client/Server Architecture 
HP MPower is shipped in a client/server configure 
allowing applications and data to he distributed across a 
networked computing environment. In a client/server archi- 
tecture, programs and data are split across the network ac- 
cording to each machines capabilities. The term server refers 
tea pn ig$&to offering a service such as faxing or printing. 
The term cheni refers to a program requesting a service, 
such as the fax composer or the HP Shared Prim client 

In today's client/server world, many services are typically 
concentrated on a powerful centra] system, which is termed 
a server system. For example, the HP MPow^er server offers 
built-in fax, mail, font, help, print, and IIP VUE services. The 
functionality available locally on the user's desktop is col- 
li < led on what we call the IIP MPower client. 

Advantages of the HP MPower client/server architecture 

include: 

• Distributed processing 

• Maximum performance measured by interactive response 
times and load balancing 

• Minimum cost-per-seal realized by RAM and disk savings 

• Scalability in that when new clients are added, the system 
administrator can cither add new servers or simply arid 
RAM and disk to existing servers. 

Fig, 6" shows a typical HP MPower client/server configuration. 
In this configuration a client can fax a document via an IIP 
MPower server 10 another client ( see i in Fig. 6). Likewise 
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Fig, 6, Faxing a tJoctarteiy betw ormected todifferenJ 

HP MPower servers* 

a client can send a document to an HP MPower server 1 pro- 
vided it offers print services) to be printed on a specific 
printer (1 i" Fig- 6). Typically, an IIP MP< iwer server pro- 
vides fax, printer, font, online help, and user interface ser- 
vices, The IIP MPower client provides local image process- 
ing, audio, video, and displa ; \| ►plications, such as 
spreadsheets, can run on Ihe server, on the client, or on 
dedicated application servers, 

HP MPower services can be split among a variety of ma- 
chines in extremely flexible configurations. For example, 
HP SharedPrint servers are installed on whatever machines 
have printers physically connected, the fax server can nut 
on a machine different from the HP MPower server, and 
there can be 1 wo or more HP VI K servers providing login, 
file and window management services for a large group of 
users. However, in arranging servkes in such a manner an 
extra burden is put on the system installer and network 
administrator* 

For simplicity, ihe HP MPower server by default nuts all the 
IIP MPower services. The III 1 MPovvei < lien! on ihe user's 
desktop runs whatever product ivily, multimedia, or user 
interface applications il ean offload from ihe IIP MPower 
server. 

Server Processes 

HP MPower server processes include the device drivers and 
the interprocess communication software shown in Fig, 5, 
The server processes in the HP MPower l.t) network include: 
1 An XI 1R5 display server with HP SharedX and vide- 1 
extensions 
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* An audio server that manages local audio hardware 

* A font server that manages the fonts on the HP MPower 
server 

• A fax server that manages local fax modems 

• A print server that manages local printers. 

These server processes enable client applications to access 
a serially reusaljle resource attached to a given host. The 
font server enables the HP MPower server to service font 
requests from all applications, affording significant disk sav- 
ings. The fax server handles file conversions (e.g., convert- 
ing from PostScript to lax-file format >, call routing, adminis- 
trative databases, and incoming and outgoing telephone 
connections. The print server employs a variety of filters to 
convert popular imaging formats to a given printer's native 
language. 

Descriptions of the audio, fax T and print server processes 
are covered in the articles on pages 62, 53. and 44, respec- 
tively, I IP Share dX t which is a tool for sharing windows, is 
described in the article on page 23. 

Interprocess Communication Mechanisms 

HP MPower employs a variety of inlerprocess communica- 
tion mechanisms to enable its asynchronous , distributed 
processes to communicate and cooperate. UNIX* domain 
and internet sockets provide most of the substrate, enabling 
remote procedure calls and event-driven protocols. Helper 
processes include a remote invocation daemon for launch- 
ing distributed applications, a broadcast message server for 
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Fig. 7. The broadcast messa^r server enables the fas composer to 
acrrpi ii dropped file from Lhe HP VI IE 3.Q B$B manager, 

passing simple strings, a location broker daemon for estab- 
lishing connections, and other standard UNIX services [ X 
server, name server, remote print daemon, NFS-mourn 
daemon, and a mail t ransport mechanism). 

For example, in extending the HP VIM o\0 drag and drop 
mechanism feo the HP MPower tools, the broadcast message 
server (BMS) provides the communication link (see Fig. 7). 

Desktop Configurations 

HP MPower provides four pre con figured desktop clients as 
Shdwn in Fig. 8, For each configuration t Fig, 8 indicates the 
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Fig. 8. Different desktop configurations provided with HP MPower. [;■) HP MPower services provided by clients and servers, (h) X station 
configuration (c) Minidient configuration, (d) MaxicLient configuration, (e) Client -on-server configuration. 
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approximate share of the HP MPower processing load that 
occurs locally on the desktop client before any other appli- 
cations are started. Fig, 8a shows the HP MPower services 
distributed among the configurations shown in Figs. 8b to 8e. 

X Station Configuration. In the X station configuration the user 
runs HP VI HE B& and the media services totally from the HP 
MPower server (Tig. 8b ). There is no local processing, other 
than flie display server portion of the XI LR5 window display 
system T HP 9000 Series :J00 and 400 workstations and X 
stations and workstations from other vendors can fundi* m 
as HP MPower X stations. These stations will run the HP 
MPower software entirely on the HP MPower server (includ- 
ing the client services), but can run other applications locally 
on r he workstation 

For more about X stations (or X terminals) see "X Stations 
in HP MPower 7 " on page 16. 

Note that the media tool software architecture shown in Fig, 
5 is not applicable to the X station desktop configuration 
because with The exception of the display and audio driver 
software all software runs on the HP MPower server. 

Miniclient Configuration. On an HP MPower miniclient most 
media services, such as audio and imaging, run locally (Fig, 
So) The user's HP VI JE session, including the file manager 
and the window manager, runs on the HP MPower server. 

The nuniclient configuration takes advantage of local HP- PA 
RISC processing power for imaging operations, such as 
rotation, scaling, and contrast. 

Maxiclient Configuration. On an HP MPower maxirlient the 
HP VUE user interface and most media services can be run 
locally (Fig. 8&)« The advantage here is that the dependence 
on the HP MPower server for the desktop user interface is 
removed, 

Client-on-Server Configuration, This configuration uses a fully 
loaded workstation, running both server and client HP 
MPower software (Fig. Be), Essentially, it offers standalone 
media services suitable for both networked and normet- 
worked environments. 

This configuration is easiest. to configure and administer, but 
it is the least cost-effective solution. Also, it is limited to 
computers thai support bitmap displays. 

Network Home 

To provide a consistent environ inenl for users whose data 
files reside on one machine and applications on another, HP 
MPower implements a network home environment. This 
environment, provides the user with a view of files that is 
Consistent across all machines in the HP MPower network. 
The user sees the same eolors, fonts, home directory, and so 
on regardless of the HP M Power client or X terminal on 
which a session is started. 

To set up the home environment, system administrators 
have three options for locating users' personal data ( i.e., 
SHOW E directories): 

• Leave the SH0ME directory on the users desktop workstation 

• Plan- the SH0ME directory on the Hi 1 MPower server 

t The new HP tNViZEX X stations otter a local flexible dish dnvB. audio, printing, and scanning 



• Place the SHOME directory on an alternate file server 

Installation and Configuration 

Because of its complex interprocess interactions and client/ 
server architecture, HP MPower depends heavily on the 
functionality of the HP-ITX operating system For example, 
HP-UX scripts are used to customize HP MPower during 
initial installation when the HP Instant Ignitiontt process is 
running. Scripts are also used to add, delete, and reconfigure 
HP MPower clients. 

Two of live mast important scripts, which are run at instant 
ignition hoot time, are responsible for setting up the HP 
MPower server and HP MPower clients. The server configu- 
ration script (setup_sen/e0 perforins the following functions 
of the server system: 

• Starts the network file system ( "NFS) for remote file access 

• Starts the NFS automounter service to provide transparent 
access to remote file systems 

• Starts the network computing system (NCS) to support 
remote printing, faxing, and audio 

• Starts the XI 1 font server so that HP MPower clients can 
obtain their fonts from the HP MPower server system 

• Starts the sen dm ail daemon so that users can send and 
receive multimedia mail. 

The setup_client c on 11 gu rati on script, which rims on the HP 
MPower client, performs the following functions: 

• Enables NFS and automounter 

• Sets up links between the client and server for the local 
client file system 

• Establishes the fax, HP Shared Print, and HP VUE 
connections to the HP MPower server 

• Enables the drag and drop capability between server and 
client. 

The system administrator can add or remove other clients at 
any time by running a simple admin_server script on the IIP 
M Power server. 

Session Startup and Login 

At later system boots (after the initial installation described 
above), the /etc/sresh script sets certain key global environ- 
ment .variables, such as the HP VUE server. On the IIP 
MPower server, the /etc/rc file starts the fax server and the 
font server processes. Other boot-time scripts start the NFS, 
automount ... and HP VI IE login processes. 

When a the user logs in through the graphical HP MPower 
welcome screen, other variables such as the users audio 
host, help path, and network home are established. 

Testing 

Because of the number of software components and hard- 
ware configurations, testing HP MPower was a daunting 
task, We concentrated on the conilguraliuns that would be 
most popular, as directed by our product marketing team, 
with particular emphasis on the IIP 9000 Models 712 and 715 
machines configured as standalone desktop clients. In the 
course of I he project, we used more than 20 integration and 
lest machines internally to verify software installation and 
i mi i figuration. 



tt Sae "The HP InstanT Ignirtan Program" on page 1 7 



)Copr. 1949-1998 Hewlett-Packard Co. 



April 1 994 Hewlett-Packard Journal 15 



X Stations in HP MPower 

The X station (or X terminal] is a product optimized to run X Window System server 
software X stations were developed when the X Window System was established 
as a standard distributed windowing system for the UNIX operating system. Three 
major factors accelerated the acceptance of X stations in the market 

• Emergence of the client/server model of corn poling 

• Dramatic increases in processor compute power 

• Improvements in networking technology. 

The X station is a network -based display device that uses X protocol over a local 
area network (LAN} to communicate with the host. The programs specially written 
for X {called clients) run an the host but display their output on the X station. X 
stations are also able to run programs locally. The programs that run locally on the 
X stations are referred to as local clients. There are three major classes of Incai 
chents; local window managers, local terminal emulators, and local utilities. 

X stations cannot operate without a host because they use the compute power, 
memory, and disk space of the host machine. 

X Stations versus Workstations 

The X station is a complementary product to the workstation m thai it offers the 
look, feel r sound, and graphics performance of a workstation, hut at a much lower 
price Typically, the X station costs about half what the comparable workstation 
costs, while providing workstation-like graphics performance. X stations allow 
multiple users to access the power of a modern workstation (host), help to make 
better use of the compote power and disk space available on the network, and 
simplify system administration X stations are not suitable for two types of users 

• Power users that run simulation and modeling programs 

• 3D graphics users. 

The reasons X stations are less expensive than workstations include: 

• They use a low-cost embedded graphic controller as CPU. A general-purpose 
processor used in a workstation is moch more expensive. 

• They need much less memory to perform the same tasks since they have a com- 
pact, real- time, UN IX -system-! ike operating system that uses only a small fraction 
of the DRAM required for a complete UNIX operating system. 

■ Most of their electronic circuitry is integrated into applicalian-specific integrated 
circuits (ASICs) to reduce cost even further. 

• They use less power, making their power supplies less expensive. 

• They do not have any hard disks. 

Configuring X Stations in HP MPower 

X stations support all HF MPower functionality with the excepliun uf a live video 
input. X stations are not true HP MPower clients. They require that both the HP 
MPower server and client run on the host. The newly introduced HP ENVIZEX 
stations support local audio, local scanner, local floppy diskette in DOS format, 
and HP SharedX functionality as a sender and receiver. The following additions 
are recommended to the .vueprofile file in a home directory for a user that uses an 
X station and the HP MPower software 

# AUDIO and SCANNER variables are derived from DISPLAY variable to ensure 

# that multiple X stations can support local audio and local 

# scanning while running HP MPower software on the same host. 

xterm_name=Sjecho SO I5PLAY sed *s;:.*;; r | 

S CAM N E R=£*t a rm_nam e 
export SCANNER 

AUDIO=S*tenn_narne:0 
export AUDIO 



iPSPEAKER-lNTERNAL 

SPEAKER=EXT£RNAL 
export SPEAKER 



# uncomment if there are no external speakers 

# comment out if there are no external speakers 



Initially, our strategy was to support as small a number of 
configurations as possible and to increase that number with 
each subsequent product release. We began by providing 
support for the Series 700 only. With HP MPower 1.2 we 
expanded that base to in elude the Series 800 as HP MPower 
servers, the Series 300 and 400 as HP MPower X stations, and 
the new ENVIZEX X stations as media-enabled X stations. 
Similarly, our first release was English only; HP MPower 1.2 
added support for Japanese and 16-bit character sets. 

The team provided an alpha release to a select number ul 
customers, which was hand-delivered and installed by a 
support group from the factory. We also created two sepa- 
rate beta releases to flush out: installation and configuration 
pro 111 ems. More than 40 internal IIP sites installed early ver- 
sions of the software. Our goal was to mininiizr the amount 
of time required to install more than 30M bytes of software. 

Twu usability tests helped shape the user interface of the 
system. We learned early that the user interfaces of the indi- 
vidual components had to change to fit the overall user in- 
teraction with the system Fqr example, all components 
adopted a uniform file selection dialog to enable users to 
access and save files consistently 

A system adnunisUation walkthrough resulted in installs n< » i 
an c I do cum entation ad\j us tments, parti c u I arly i n orgar 1 1 / i n g 
the system installation into separate procedures lor instant 
ignition and noninstant ignition systems, The prerelease 
feedback enabled us to cut the installation time from two 
weeks (at the project outset J to l wo days (at alpha release) 
to two hours (for the final product), 

We divided testing responsibility among tbe component 
owners so that one team tested the fax, imaging, audio, and 
other media components, another team tested" the HP 
SharedX and whiteboard components, and a third learn cov- 
ered the mail desktop integration, and system installation 
areas. We relied extensively on an automated defect track- 
ing system for monitoring defect levels and resolution rates 
on a weekly basis. 

We performed a limited set of code inspections on new and 
critical modules. Team members spent many hours testing 
the components and system interactions manually. They have 
since started work to automate a number of these tests. 

Diagnostics 

HP MPower has a diagnostic facility called Dr_M Power which 
consists of a variety of submodules that check dozens of key 
system and personal files to ensure that the system and the 
media services are properly installed and configured. 
Dr_ MPower can be run on either a server or a client. 

Users can rim Dr_ MPower simply by double-clicking the tool's 
icon in i he file manager toolbox. See the article above for 
more about this diagnostic. 

Challenges 

Besides working on a tight schedule, some of the challenges 
we encountered while developing the first HP MPower 
product included: 

{continued on page 18} 
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The HP Instant Ignition Program 



The HP Instant Ignition program is focused on increasing customer satisfar. 
delivering a compete, Integra:- g ^red systemf that rs ready to use The 

program has the followpng goats: 

• Give the customer a positive 'our of The box" experience (i.e.. a positrw ; 

essiooof oursys*- 

• Decrease the "time to productive use of a system 

• Decrease HP's field and factory cost by using common tools and standardized 
processes 

What Is an instant Ignition System? 

The HP Instant Ignition system is made up of the basic computer system hardware, 
including a disk that is preloaded with an operatmg system, optional application 
software, and system documentation. 

The HP Instant Ignition design team set out to make HP 3000 systems less intimi- 
dating to the user. The team designed a number of usability enhancements aimed 
at addressing the program goals. For example, esoteric messages were removed 
from the boot process. The team replaced other messages with a concise checklist 
that indicates passing or failing portions of the hoot procedure (Fig. 11, labels on 
boxes were enhanced to make them more readable 

Addition ally, the first time the svstem is booted, the user is prompted to provide 
system parameters that cannot he predicted in the factory, such as networking 
specifics This method of configuring the system eliminates the need for a user to 
edit files manual I y. 

The HP MPower team designed an extension to these system parameter prompts. 
The links between the client and server are established as the system is booted so 
that HP MPower is fully functional the first time any user logs into the system. 

CHAMP 

To preload the various operating systems and applications, the instant ignition 
team developed a software tool called CHAMP (channel-reseller and manufac- 
turing process). CHAMP fits into an automated hardware manufacturing line at a 
point where the CPU is assembled with a disk and diagnostics have successfully 
completed. At this point, the customer's disk is ready tn be built using a two-phase 
process. 

First, the customers CPU boots from a dedicated manufacturing disk that contains 
the CHAMP tool. CHAMP runs on the customer's hardware and downloads the 
operating system to the customer's disk or target disk. CHAMP then downloads 

t CuTiently HP 9000 Series 7D0 and 8D0 machine 



HP-U X Start-up In Pracsss Status 

initializing System [OK] 

Starting Networking [OK] 

Staning Diskless Cluster Client [ OK ] 

Starting Systum Flint; I ions I OK j 

Starling Auditing [ OK ] 

Starling Diagnostics f OK ] 

H P-UX Start-up In Process Status 

initializing System ( OK ] 

Sta Hi ng Networking [ FA I L j* 

Starting Diskless Cluster Client [ OK 1 

Sta rl i rig S yste m Fun c ri ons [ OK ] 

Starting Auditing [OK] 

Starting Diagnostics I OK ] 

NOTE: An error has occurred! 

Refer to the tile /usr/adm/rc.log for more information. 

Press [Return] to continue. . . 



in.l 



Fig. 1. An HP Instant Ignition boot checklist jaf When things are OK. (b) When ffings.ws 
natOK 



some utilities to the target disk to prepare for phase two The last thing to occur in 
phase one is to reboot the customer's system 

In phase two, the customer's system boots from its own disk, the target disk 
cr eaten -.ad of bootmg to the login screen as expected, 

the s wn loaded in phase additional soft- 

ware. This software may come from a netriisi server or from another system on the 

The system will also configure its kernel if necessary, based 
customer's hardware and optional software 

The last thing to occur during a CHAMP build is to remove the CHAMP utilities and 
return the operating system to a pristine state The system then shuts itself dawn 
and is ready for the customer. 

Design Considerations 

In designing CHAMP, a number of requirements had to be met Some of the key 

design requirements were to" 
» Preload HP 9DOQ Series 700 and Series SQD HP-UX operating systems 
* Run from a command Nne r allowing existing manufacturing processes to invoke 

CHAMP automatically 
i Run on the customer's hardware (This guarantees that the HP-UX kernel and the 

recovery instructions are specific to the customer's hardware.) 

► Load application software that is delivered in a variety of formats [HP's preferred 
method for packaging software is update format The utility /etc/update is a stan- 
dard part of the HP^UX operating system and is available to internal and external 
customers, CHAMP is flexible enough to load software in other formats, such as 
tar and cpioj 

► Load software in sequence (This means that if application 1 must be loaded be- 
fore application 7 t CHAMP can accommodate this sequence.) 

► Generate customized recovery instructions for each system. (These instructions 
outline exactly how the system was created in manufacturing sd that the customer 
can recreate the original system in the event of a disk failure. These instructions 
are online in a file, and a hard-copy version is added to the shipping boxes at the 
final staged the manufacturing process.) 

Other Uses for CHAMP 

It became evident that CHAMP had potential uses outside of HP's manufacturing 
process. For instance, resellers could be more effective in delivering HP Instant 
Ignition systems if they had access to CHAMP and if CHAMP was easy to use and 
maintain. 

While flexibility is one of the outstanding features of the CHAMP tool flexibility 
does not always equate to ease of use. To enhance usability, a graphical user 
interface was layered onio the basic CHAMP tool, With this interface, CHAMP is 
very easy for the nonexpert, such as a reseller, to use to build preloaded systems 
quickly 

CHAMP is also used by operating system and application developers internal to 
HP f hese developers can use CHAMP to build a test system for their development 
It takes about 30 minutes to create a new HP-UX system using CHAMP This is 
considerably faster than using CD-ROM media to build a new system. All HP teams 
that develop pieces of the HP-UX operating systems and preloaded applications 
are required to Eest their software on the base system buill by CHAMP 

Conclusion 

Customer acceptance and popularity of the HP Instant Ignition program continues 
to grow. Customers like to receive their systems with preloaded software. Today 
rho HP Instant Ignition program is limited tu preloading HP applications because of 
interna! issues related to selling and preloading third-party software. 

Sue Magenis 

Development Engineer 

Open Systems Software Division 
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Diagnosing and Reporting Problems in the Multimedia Environment 



The need for installation and configuration diagnostics for user interface software 
became apparent soon after Ttie release of HP VUE 2.D. Because of the large 

number of files associated with HP VUE and the dissemination of those files 
across the file system, response center! engineers were spending a lot of time 
telling customers about which files to check for known problems. An analysts rjf 
call-in data from the Atlanta response center revealed Ttiat the amount of time 
spent each quarter handling HP VUE configuration questions was rising rapidly 

As a result of this feedback, the technical training and support group in Coryell is 
decided that a script or program could more efficiently wander the highways of 
the file system and check on the existence, permissions, and ownership of most of 
the files that HP VUE depended on. Key files, such as /usr/adm/tnetdsec, /etc/inittab, 
and others could be searched with standard tools to determine if the attributes 
required for certain entries were proper. The use of a script could reduce the 
amount of time required to check basic configuration issues from hours or days to 
a matter of a minutes Thus, Dr_VU£ (diagnose and report Visual User Environment 
problems) was born 

Dr_MPower is a direct outgrowth of Dr_VUE Dr_MPower consists of a collection 
of diagnostic tools used to help debug installation and cunfiguration problems in 
the HP MPuwer environment. Since HP K/IPower combines several disparate appli- 
cations, we decided to create a separate script to check each individual compo- 
nent This resulted in a total of 1 2 scripts, one each for ID components of HP 
MPower; a file that contains common functions used by each of the scripts, and a 
calling script. The calling script is Dr_mpower. which does some checking of sys- 
tem functions and then calls each of the remaining scripts in turn Since HP 
M Power makes heavy use of the HP VUE environment, an action was defined to 
initiate Dr_MPower. This action is located in one of the toolboxes available to all 
users, A simple double-click on ttie Or_MPower icon results in a new terminal 
window that displays the information output by Dr^M Power. Each of the scripts 
called by Dr_M Power can also be run individually to perform checking on The 
separate components of the HP MPower environment. 

A myriad nf configuration issues exist in the HP MPower environment Dr. MPower 
certainly does not check each and every possible one, but Taiher looks at what we 
hope to be the vast majority of them. Since the MPower environment consists of 
servers, max ic I ients (clients running HP VUE locally), miniclients (clients running 
HP VUE on the server}, and X terminals, the first thing that DMvtPower needs to 
determine is the type of system it is running on When this has been accom- 
plished, Dr_MPower will check items specific to that environment Tor example, 
there are differences between the client and the server in recommended kernel 
parameters, as well as certain processes that run on the server and not on the 
client. Another difference is the fact that the mmiclient does not run HP VUE 

1 HP has several locations worldwide that are responsible for handling software or hardware 
problems from cusiomers who have pjichased response-line support contracts. These 
locations are called response centers. 



locally, so the check_vue script that is called by pr_MPower should not be run for 

that platform 

The installation and configuration of HP MPower makes heavy use of scripts, and 
since scripts fail occasionally, Dr_MPower attempts to verify that all the actions 
performed in the various configuration scripts have been accomplished. An exam- 
ple is checking in the file Mc/netnfsrc to see if the parameters NFS CLIENT. 
NFS ..SERVER, and START MOUNTD were successfully set to one by the configure* 
tion scripts. Another example is checking to see that a line was added in /etc/rc to 
start the font server and that the font server is currently running. Fig. 1 is a graphical 
representation of the components checked by Dr_MPower 

Anytime Dr_ MPower encounters something that appears to be in error, a message 
is written that attempts to inform the user as to the seventy of the problem with 
either INFO, WARMING, or ERROR statements Isimilar to the feedback seen in an 
update log). If possible, an appropriate course of action is also given. For example, 
a check is made of the /etc/src.sh file to determine if the configuration script 
added two entries specifying the HP MPower and HP VUE servers. The following 
code performs this check and issues a WARNING statement if the installation 
script did not add the entries in lhe/etc/src,sh file: 

## look in Mc/src.sh to see if VUE_ SERVER and MPGWEFL SERVER were 
## added 

coum^Stgrep -a VUE.SERVER -a MPOWER.SERVER /etc/src.sh 1 wc ^1 

| Scoont -eq 2 ] 11 

prim "WARNINGS he MPower installation script should have added 
two entries to /etc/src.sh. 
VUE_5ErWER=Sh05tnarrie; export VUE SERVER 

MPOWEA_SERVER=$hosti>ame; export MPOWER_SERVER 

This does not appear to be the case. You should rerun the 
/osr/MPowerServer/setup_server script or add thess 
lines yourself.'' 

This code performs the check and provides the user with two options to correct 
the perceived problem: either manually add the entries or rerun the configuration 
script that should have made the additions 

There are over 400D lines of code in the various scripts that make up DMVTPower. 
Considering the positive feedback we have received from support partners con- 
cerning Dr_VLfE. we are confident that the Dr_M Power scripts will significantly 
reduce the time spent supporting customers with HP MPower problems. 

John V Peterson 
Support Engineer 
Workstation Group/Corvallis 



• Geographically separated teams. The HP MPower project 
team included members from Oregon, Massachusetts, 
California, Colorado, and Canada. Keeping the lines of com- 
munication open and efficient helped us understand some 
of the requirements of distributed work groups. 

• Integrating disparate components. Initially, team members 
designed their products (such as fax and whiteboard) as 
standalone applications. Achieving a common look and feel 
involved changing parts of our HP MPower subsystems 
such as interprocess communication mechanisms, icon 
visuals, online help, and dialog box behavior, 

• Incorporating a common file-typing mechanism. The HP-UX 
file system is designed to treat all files simply as bags of 
bytes. Within a graphical user environment, it is necessary 
to know file types to determine the appropriate actions for a 
given object (e.g., mail, print, edit, fax, play, and view). To 
preserve the file types of IIP MPower media objects, we 



implemented a variety onile-typing mechanisms, ranging 
from appending file name suffixes to inspecting file contents. 
Living within workstation resources. OSF/Motif applications 
are quite large. Thus, ruiuiing a variety of OSF/Motif- based 
applications and a myriad of server and helper processes on 
limited-memory systems forced us to adopt a client-server 
architecture. 

• Large media objects. Media objects are by nature large- For 
example, a sound clip can cosi 16K bytes per second, mid 
each video frame can cosi almost a megabyte We use a 
number of compressed file formats to keep file sizes to a 
minimum such as the JPEG file format for video images. 
Fortunately, the processing power of the HP PA- RISC-based 
workstations makes the compression and decompression of 
media objects a fairly painless process. 

* Configuring the distributed environment. System adminis- 
tration burdens can grow exponentially when services are 



1 8 April l PS4 I lewteU-Paekard Journal 



)Copr. 1949-1998 Hewlett-Packard Co. 



Media 




ci*cii_f*i 



check image 



check ..shared X 



i. 



•yiiii'M 



Fig. 1. The HP MPower components checked 
by D/_MPgwer and I he associated scripts 
responsible far making the checks 



distributed over several hosts. By offering a fairly restricted 
default configuration, we have reduced Hie headache of 
installing ami maintaining HP MPower nodes. 
* Living in the network home. Today s users are familiar with 
desktop computing, in which most of their applications and 
data reside on their local machine. When their environment 
is distributed across multiple hosts, users can become dis- 
oriented in the network environment. We have tried 10 make 
file access &s transparent as possible and to invoke appi !■ i 1 
tiorus on the expected host. 
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A Graphical User Interface for a 
Multimedia Environment 



The HP Visual User Environment, or HP VUE, provides not only a friendly 
user interface to the HP-UX* operating system but also a framework for 
the HP MPower system. 

by Charles V. Fernandez 



It was inevitable that once the multitasking, multiuser, and 
network capabilities of the UNIX* operating system were 
connected with the power of graphics workstations that the 
next step would he to civilize the UNIX command line inter- 
face with a graphical user interface (GUI), Graphical user 
interfaces are literally changing the face of UNIX systems, 
and in doing 80, are helping to spread UNIX systems and 
workstations from their historical installed base among tech- 
nical users into the broader markets offered by commercial 
computing. 

Among these GUIs is the HP Visual User Environment 
(IIP VUE). HP VUE is the first GUI to provide I he following 
features and capabilities for workstations running the 
HP-UX operating system: 

• PC-compatible controls 

• 3D visual appearance 

■ A graphical user interface to the system's particular 
functionalities while hiding the peculiarities of the system 
from the end user 

• Multiple levels of integration for in-house and ISV 
( independent software vendor) applications. 

As the framework for HP M Power, HP VUE provides the 
structure into which multimedia components can be 
integrated. 

HP VUE provides a consistent set of controls with which to 
operate a workstation. While UNIX system commands con- 
tain a lot of functionality, this functionality is often cryptic, 
hard to understand, and difficult to remember, especially for 
occasional users. Additionally, UNIX system commands and 
their options are often inconsistent (some commands provide 
output, others don't, and what an -□ option means depends 
on the command, not the functionality of the option). IIP 
VUE changes all this. IIP VUE uses a simple set of graphical 
controls, consistent with the Common User Access (CUA) 
model followed by Microsoft/ IBM Corp., and many other 
PC manufacturers. The CUA model is based on pushbuttons, 
scroll bars, and menus. 

A user familiar with similar controls such as Microsoft 
Windows can sit down at a workstation with an IIP VUE 
user interface and immediately take control because the 
skills required to operate a PC GUI axe the same as the skills 
needed to operate an HP VUE workstation. 

To operate a UNIX system from the command line, a user has 
lo type commands and command options at the keyboard A 



spelling mistake or a typing error could mean disaster. Com- 
mands t unless memorized, have to be looked up in the docu- 
mentation, HP VUE unburdens the riser from having to 
memorize UNIX commands and retype faulty command 
lines. To operate an HP-UX system from IIP VUE, a user 
directly manipulates the graphical objects that populate the 
workspace. For example, to move a file from one directory 
to another, the user drags the file icon from one Tile manager 
view to another and drops it there. To start an application, 
the HP VUE user double-clicks tire application icon. 

One of the confusing things for users of an operating system 
is that they are required to develop a three-tiered level of 
consciousness: one level for the operating system, one for 
the application, and a third for their data, the only tier they 
are really interested in. New users have a difficult, time dis- 
tinguishing where one level stops and I he oilier starts. Com- 
mand line environments routinely demand that a user who 
wants to access data must switch from a data focus, remem- 
ber which application works with that data (and possibly 
where that application is located), and negotiate how to 
start the application. Only after successfully starting the 
application can the user return to the desired data Torus 

HP VUE, on the other hand, because it associates applica- 
tions with data using an action and file-typing function, en- 
ables users to remain focused on their data, and the operat- 
ing system and application tiers remain iiidden by the user 
interface. To access data in the HP VUE environment, users 
doubleclick the data icon. The application starts automati- 
cally and loads the selected data file, leaving the user free to 
focus on work, not the mechanics of getting to work. 

The HP VUE 3.0 Design Process 

Getting IIP VUE to its current slate has been an evolution- 
ary process. The process began in the mid-1980s wiien IIP 
adopted the X Window System as the strategic graphical 
layer for workstations. This evolution continued through the 
development of the 3D window manager, hpwm, its submittal 
and acceptance by the Open Softw r arc Foundation (OSF) as 
an industry standard, the proliferation of OSF/Motif, the 
development of IIP VUE 2,0. and finally, IIP VUE 3.0. 

During the design process of IIP VUE 2.0 it became apparent 
that designing a user interface without user input would be 
a recipe for disaster. For the development of HP VUE 3.0. a 
more formalized approach to user input was established. This 
approach goes by the acronym QFD, for Quality Function 
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Deployment- l It was adopted for the development of HP 
TOE 3.0 to help ensure that 

• Customer input was systematically collected 

• Customer input was quantified to define and priori ttze 
product requirements 

• Customer input was factored into the design process 

• Product design was affected by the input as opposed to the 
input being interpreted to fit the design. 

The QFD for HP YUE 3.0 was a multistep process. Keeping 
in mind that the primary targe! market for HI* VUE eon- 
of workstation users, we established a target design market 
for HP VUE 3.0 in I he areas of factory floor operations, 
scientific research, industrial and architectural design, infor- 
mation engineering (knowledge workers), design engineer- 
ing, education. CASE (computer-aided software engineer- 
ing), and system administration. These design markets were 
given relative weights to facilitate the prioritization of then- 
inputs. For example, input from scientific research with a 
weight of 5% wasn't nearly as influential as input from a 
knowledge worker with a weight of 35%. Within these areas, 
potential users were categorized on a UNIX knowledge-ability 
spectrum that included categories for protected users, naive 
users, moderate users, and sophisticated users. Correlations 
were noted between these user types and our target design 
markei. ( >ver 30 companies were visited and asked to input 
into the HP VUE 3.0 QFD process. 

The result was a weighted list in priority order of what cus- 
tomers wanted. Performance figured high on the list, Pizssazzt 
was also important Of less importance were multiple fonts 
and workspace manager button lahels. This list essentially 
formed a prioritized functional specil1c.it ion wish list for the 
HP VUE 3,0 product 

The Workspace Manager 

HP VUE 3.0 workspace manager has a new look thai differ 
entiafes it. from HP VUE 2,0, This new look is pari pizzazz 
and part pragmatism. The pizzazz is that the square button 
look of the 2.0 front panel is replaced by a meuihraiie" look 
in which the bevels detnarking the hut tons are removed and 
the icons that form the button labels appear inset into the 
front-pan el me m bran e . 

Fig. 1 illustrates the familiar ^boxy* look of the HP VUE 2L0 
front panel and the new and improved membrane 1* m k ol (In 
HP VUE &0 front panel. Notice also the slide-up sul>p;mels 
available with the IIP VTjE 3.0 front panel. The tall subpanel 
on the left is the IIP MPower media panel HP VUE &0, as 
mentioned earlier, provides the framework for HP MPower. 

Aside from supplying an easily recognizable visual distinc- 
tion between I he two versions of HP VUE, the membrane 
look makes I he front panel easier to configure. To place a 
button in the Old front panel required users to count the 
length and width of a button in pixels and then add pixels 
for die bevels. This proved to be a time-consuming and 
error-p rone act i lity an d c ertah i \y not i tser- f ri e n < Uy. TI te 
membrane look eliminates I lie need for users to could pixels. 
They simply specify die button, and the front panel magically 
grows itself to fit the new button. 

t Pizzazz refers m those f&aiufes in a product thai might create customer fiNGftwnfiftt ■>- Q 
garbage can icons that open when trash is tossed in or button icons that look and behave 
like real pushbuttons ). 




(a) 




HP VUE 
Pane 



4b) 



Fig. I. I ; ' in- bexy' 1 look of the HP VUE 2.0 front panel and 
(h) the new and improved membrane look of tl'i*? HP VUE &0 front 
panel inc I u dii ig I he H P M Po we t slide-up si the left. 

Another pizzazz and functional feature of the new front 
panel is the inclusion of slide-op sabpanete. These panels 
slide up seemingly front behind ihe front panel when their 
control is pressed. The slide-up subpanels enable developers 
to make more rout mis readily available without taking up 
more space. They also provide a convenient place to locate 
Ihe multimedia components of HP MPower. The slide-up 
subpaneis Cfttl be lorn off and posted to the workspace like 
a control panel 

The File Manager 

The file manager is a good example of how QFD and usability 
studies can refine a product I LP VI E 2,0 parked a lot of 
functionality into the file manager Virtually all system file 
management was available through the file manager's GUI 
This is a good thing. However, what the 2.0 file manager 
didn't do T and what QFD and usability studies made apparent, 
was that all that functionality wasn't readily accessible. 

The best example of this is Ihe process of renaming a file. To 
rename a file in HP VI 'E 2.0, the user had to do the following: 

• Select the file to be renamed 

• Pull down the Rle menu 

• Select Rename from the menu 

• Wait for Lhe Rename dialog hox h> appear 

• Click the Rename text entry field in the dialog box 

• Type the new tile name 

• Click the OK button. 

As a result of feedback from QFD and the asability studies, 
the HP VI IE 3.0 file renaming process involves the following 
steps: 

Click on the file name to change 
t Type the new name 

• Press the Return key, 
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Visually the file manager didn't change that, much between 
HP VUE 2,0 and HP VUE 3.0. However, tlie difference in ease 
of use and accessibility to file management functionality is 
quite significant. 

The Style Manager 

The HP VII E 3.0 style manager is another component that 
shows the subtle but. unmistakable signs of the QFD pro- 
tress. While the work environment at HP is fairly open and 
users are fairly knowledgeable about the UNIX operating 
system ? some of the system administrators and managers 
from customer sites often had more controlled environ- 
ments for security reasons. Their- feedback was the impetus 
for removing the Host dialog from the style manager. They 
wanted control over the X Window System's ability to host 
"foreign" workstations. Also, for security reasons, I hey 
wanted to control the ability of one workstation to host 
other workstations. 

Along the same fines, security-conscious QFD participants 
requested that the little lock icon that appears on a locked 
workspace be changed to a full screen cover so thai a 
passerby could not read information visible in the windows 
left open on the workspace. 

Performance 

Talk about graphical user interfaces long enough and 
eventually the discussion will get around to performance, 
Since HP VTJE 2.0 is the most visible part of the operating 
system, il bore the brunt of a lot of negate performance 
comments. 

Some of these criticisms, like "HP VUE is a big memory 
consumer because it takes up 16M bytes of RAM," are tin- 
deserved. HP VUE isn't really a heavy memory user, but to 
many users it may seem to be so. On a typical workstation 
with IfiM bytes of RAM, the RAM is apportioned roughly as 
follows: 

Miscellaneous Daemons 3M bytes 

Kile Buffers 3 M bytes 

Kernel 3M bytes 

X Server 2M bytes 

Workspace Manager 1M byte 

File Manager Q,75M byte 

Help Manager 0.75M byte 

Style Manager 1M byte 

Hpterm Console 0.75M byte 

Message Server Q.5M byte 



Total 



15. 75M bytes 



Nearly three quarters of the 16M bytes HP VUE is suppos- 
edly hoarding is actually being used by core system func- 
tions. The point that is most often misunderstood about HP 
VTJE is that it is not a monolithic application, but a set of six 
components, not all of which need to be mnning at the same 
time. When something Isn't running or being currently used, 
it is pushed out of RAM. As a matter of fact, at a minimal 
level j the user can run the workspace manager and receive 
the benefits of multiple workspaces for tittle more cost in 



RAM than would be experienced with using a standard 
OSF/Motif window manager. 

One of the criticisms that HP VUE does deserve is for the 
amount of time il lakes to log in, For HP VUE 3.0, perfor- 
mance, as mentioned above, was a key design area. Besides 
speeding up the access to functionality like renaming Tiles 
which increased perceived performance, all HP VUE compo- 
nents and major processes were studied, including login, log- 
out, file management, and session management t 'ustomers 
were asked what trade-offs in functionality would be accept- 
able for the sake of better performance. Out of this research 
came a number of improvements. Instead of starting all HP 
VUE components immediately at login, their individual 
starts are staggered. Studies show T ed that starting processes 
all at once caused tremendous contention for RAM, while 
actually delaying a components start until the preceding 
component was fully started. This staggered start of all 
processes reduced overall startup time. 

Another result of the HP VUE 3.0 performance work was 
the development of a lighter-weight version of HP VUE. 
This lighter version of HP VUE has two of the most RAM- 
expensive components removed: session and file manage- 
ment. Reliance on a default HP TOE session instead of true 
session management speeds up the login and logout pro- 
cesses. Using the file management functions available on the 
file menus of all standard OSF/Motif applications instead of 
the III 1 VUE file manager avoids session slowdowns caused 
by the file managers periodically jumping into RAM (and 
pushing the resident application out) to check thai its file 
views match the current file structure. 

Conclusion 

One of the most gratifying results of the HP VUE &0 QFD 
effort was the affirmation from customers of our belief that 
a GUI is a work in progress, an evolutionary process. Dra- 
matic differences between HP VUE 2.0 and HP VUE 3,0 
were both uncalled for and unwanted. What customers did 
want was evolutionary changes, such as to make it easier to 
rename a file and configure the front panel. Our QFD cus- 
tomers were very at timed to HP VUE as an environment 
from which to access their working applications. Under- 
snmdmg their vision enabled us to take the next step in HP 
VI "E n s evolution: making HP VUE the framework for HP 
M Power. 
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HP SharedX: A Tool for Real-Time 
Collaboration 



With this real-time communication product two or more remote users can 
share and interact with the same X-protocol-based applications from their 
workstations. Windows are shared in such way that it almost seems as if 
all the participants in the shared session are sitting at the same 
workstation, running the same application. 

by Daniel Garfinkel, Brace C. Welti, and Thomas W. Yip 



HP SharedX is a communication tool thai extends the 
industry-standard X Window System to enable real-time 
sharing of X-protoroi -based applications between two or 
more remote users and displays. With HP SharedX users can 
share information with one another via a workstation with- 
out being in the same location. 

Being ahle to share information over a network in real time 
is a very effective productivity tool. The following two ex- 
amples show how displaying applications across a computer 
network can increase productivity: 

« System administration. Mary is a system administrator for 
several networks distributed over several widely dispersed 
buildings. When a user on a particular network encounters 
what may be an application or system problem, Mary can, 
willr the user's cooperation, establish a common (HP 
SharedX) window with the users system. Wiih this shared 
window Mary can see and diagnose the users problem 
while the user is watching what she is doing. She can per- 
form this task without leaving her desk, using the diagnostic 
tools available ;ii her workstation. 

• Remote demonstrations. For some new or complex software 
packages, there may be only a handtul of people who are 
able to demonstrate the software effectively. HP SharedX 
gives these people an opportunity to have a virtual presence 
at remote locations on the network. Hewlett-Packard's Work 
Management Operation routinely uses HP SharedX to dem- 
onstrate advanced features of its HP WorkManagcr data- 
base product from the desks of engineers in Fort Collins, 
Colorado to prospective buyers all over the world. Also, 
various partners who are developing additions to Work- 
Manager use HP SharedX to demonstrate their work in 
progress to the engineers in Fort Collins, allowing ncw r 
features to be evaluated "live" without travel 

HP SharedX can accomplish display sharing because of the 
nature of the system it is built upon, the X Window System ^ 
The X Window System, known simply as X, is a networked 
window system allowing X applications running on one 
computer to display on another (see U X Window System 
Clie n t/Server Architecture" on page 25); Tins networked 
aspect allows sharing of expensive high-speed computers 
among several users on low -cost X- based display stations. 



Furthermore, X is designed to be inter operable in heteroge- 
neous computing environments. Applications running on one 
vendors hardware can display themselves on another ven- 
dors display by adhering to the X protocol standard. Hetero- 
geneity is accommodated by abstracting the applications 
view of the display subsystem, including the graphics hard- 
ware, input device control, memory management, and data 
formats. Interaction with the display station occurs through 
a well-defined protocol, which provides a consistent way for 
applications to work with a wide variety of display devices, 
from PCs to high-resolution t deep-color workstations. 

X has become I he industry standard window system for 
workstations in part because of its networked and heteroge- 
neous nature. HP SharedX builds on the X Window System 
by retransmitting the X protocol stream to multiple X display 
stations, I hi is simultaneously displaying a single application 
on multiple computer displays. Some key features of IIP 
SharedX are: 

* No changes are needed to existing X applications to share 
them. HP SharedX allows users to share virtually any X ap- 
plication, rather than forcing users to use specially written, 
collaborative applications. 

* Users see a copy of the application to the best ability of 
their display device, If necessary, HP SharedX will degrade 
the quality of the displayed images to match the capabilities 
of the display hardware, 

* Running applications can be shared without prior setup. 
Users need not restart applications they want, to share; the 
application can be shared in its current state. This is impor- 
tant in consulting environments where users may not know 
how they gol their application into its current slate. 

* The receiving machines (machines receiving I he shared 
application) need no modifications or special software 
installed. Since X protocol is the communication mecha- 
nism, the receiving machine can be any X -capable display 
device* 

* Receivers of a shared application can interact with it as well 
as the sender (the machine sending the shared application). 
Lv< rivers can demonstrate operation ot the application 
rather than describing to I he sender what to do. 
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Sender 



Receiver 




Workstation Display Workstation Display 

Fig* 1. HP SI tan -flX sender/receiver architecture and data flows during initial display connection 



The rest of this article covers the architecture of the HP 
SharedX system, the user model and user interface for shar- 
ing, an overview of the low-level mechanism that multicasts 
the X protocol and merges input even Is, and finally, a de- 
scription of how sharing is accomplished with displays of 
different visual types and different resources. 
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Receivers Windows Tools Options Help 
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HP SharedX Architecture 

HP SharedX consists of three components; the HP SharedX 
user interface (known as the connector), the HP SharedX 
receiver service, and the IIP SharedX extension to the X 
server (see Fig, 1 ), The connector is the sender's control 
for sharing and unsharing windows, enabling and disabling 
receiver input, displaying sharing status, and so on. The re- 
ceiver service is an optional process on the receiver's ma- 
chine that simplifies sharing windows and increases security. 
The IIP SharedX extension is a low-level mechanism that 
shares windows, keeps those windows up to date, and 
merges input from multiple users. These three components 
are described in more detail later 

An IIP SharedX session begins when the user at the sending 
workstation specifies a receiver and pushes the Share button 
in the IIP SharedX comiector window ( Fig r 2 ), After the Share 
button is pushed the sender selects the window to share by 
clicking the mouse button over the desired window. Once 
the desired window 7 is selected the following events occur 
between HP SharedX processes on the sender and receiver 
workstations shown in Fig. 1. Each step corresponds to a 
number circled in Fig. 1. 



Input 



Receiver List 



iDan Garf inkel 



Bruce Welti ........... 

Tom Yip . 



Share 



Unshare 



Disconnect 



Fig. 2. The HP SharedX connector window; 
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X Window System Client/Server Architecture 

Ihe X Wimfcra System, coftironty refercsd to 3s X, is an industry-standard, networiV 
transparent window system X presents so the user a hiererchv of resizable over- 
lapping windows providing device independent graphics A graphical user interface 
is commonly included as an integral part of ifie X Window System 

The principal feature that d<st i r ■ g m a conventional wmdo v. 

its network transparency The X Window System allows window ape 

clients to access rjie display only through the X server, which is a separate process 

that arbitrates resource conflicts and provides display, keyboard, and mouse 

vices to all clients accessing the display (Fig, 1| X can support a spectrum of 

hardware displays ranging from small monochrome units to advance 

systems with up to 32 bits of color per pixel 

The client and the server exchange information only by means of the X Window 
System protocol which can be implemented via any reliable byte stream In the 
HP-UX* implementation of X, as in most others, this byte stream is implemented 

as a socket, whicti is a logical data connection between two processes on the 
network Clients may reside locally with the display sewer or on a remote system 
across the local area network ILAN} A performance optimization bypasses the 
physical LAN when the client and the server are on the same computer 

Because the client program and the display server are two separate entities, the 
target display can be specified at the time the application client is run The client 
program is indifferent It sends out X protocol commands via calls to the X library 
(Xlib), which in turn calls the network service functions to communicate with the 
target X server 



Appli«iiw 



Ustf Interface Toolkit 



X Library (Xlib) 



Network Services 



LAN 



Network Services 




Display 



Fig, t X Window System nliem/server architecture 



1. The connector sends a message over the network to the 
IIP Share dX receiver service on the receivers machine. The 
receiver service displays a window 7 asking the user aJ Hie 
receiver system to accept a shared window from the sender 
(Fi*:S). 

2. The receiver passes hack a yes or no response lo the 
connector, If the answer is no, the sender is Informed that 
access is denied to the receiver's machine. 

3. If the answer is yes (or if the receiving machine does rn «i 
have the receiver service), ihe connector sends a special X 
protocol request (share window W lo receiver R'2\ to (he 
senders x server. The X server's main event loop recognizes 

Hie share window request as one directed ;il Ihe UPSharedX 
extension, ll calls Ihe appropriate function in the extension 
to handle the request 



Do you want to receive a window from: 



| Yes No 



Bruce Welti 



Options Help 



-L 



4. The HP SharedX extension opens ;i connection over die 
network tothe receiver's X server This is done with the Xlib 
call XOpenDisplay. 

5. The HP SharedX extension creates windows on the re 
ceiver's screen to match those on the senders screen, 

(l. As the \vindnus are created and mapped, the receiver's 
X semi generates a request to redraw the newly created 
windows, 

7. The application responds I >y rei I raw log the contents Of all 
of its windows. X protocol drawing requests to redraw the 
windows are handled locally by the sender's X server, as 
usual, bill since the application is now shared, die proiocoJ 

etively echoed to die receiver \ | in Fig, I }. This is 
how the receiver is brought up to date with the sender when 
the share is initiated. Incidentally, none of the resoun es 
(graphics contexts. Touts, and soon) exist on Che receiver 
when the requests start flowing from die shared application 
Resources on the receiver are created when they are needed, 
that is, al the point they are first used, and not when they 
are created by the shared application. As a result, the input 
front the application lo the sender's X server and output 
from the senders X sewer to the receiver's X sewer might 
look lik*- the following streams: 



Input 

ClearWindowj win! ) 

DrawLme( win!, gel, x, y ) 
DrBwLine( win2 + gc2 H x, y } 



Ouipur 

ClesrWindow( wmla } 
gcla - CreateGCt wm1a« 
DrawLinef winla, gcla, x ( 
gc2a - CreateGC( win2a, 
DrawUne( win2a, x ( v I 



f) 



Fig. 3. The Hrsh.jh .|\ rei eivei ervice window. 
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Graphics Glossary 

The following are some graphics terms that may be of help in reading parts of this 
article ttiat discuss graphics . 

Color Map. A very high-speed look-up table that maps the numbers stored in the 
frame buffer (video memory) to actual color values which are converted to analog 
voltages and sent to the monitor 

Frame Buffer, The video memory of a dtsplay device in which each element 
represents one picture element, or pixel. The frame buffer is divided mta two 
parts: onscreen memory Current visible image} and offscreen memory (graphics 
memory that is never visible). 

Graphic Context A set of attributes such as foreground and background colors. 
line styles, and fill patterns which are used by X clients to specify how the X 

server should render the drawing requests it receives 

Image Planes, The primary display memory on HP's display systems, used for 
rendering complex images. 

Offscreen Memory. A portion of the frame buffer that cannot be displayed Dn 
the monitor In ail other respects, offscreen memory behaves the same as on- 
screen (visible) memory, Starbase and X use offscreen memory to hold character, 
cursor, pixmap, and scratch information for rapid transfers to onscreen memory 

Pixmap. A rectangle of image data maintained in offscreen memory when there 
is room, and in virtual memory when there is no room in offscreen memory. 

Rendering. Any form of drawing operation, including text, line, and raster output 
Rendering may occur to onscreen memory, offscreen memory, or virtual memory. 

Visual Type. The color map capabilities of a given display. Common visual types 
supported on HP displays include 1 -bit static gray (or monochrome), B-bit pseudo 
color (having 258 color map cells of RGB values), and 24-bit direct color [using 8 
bits each for red, green, and blue values}. 
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Nate that these are only representations of the drawing 
commands sent from the application and the sender's X 
server. The parameters win! a and win2a correspond to the 
different windows created in step 5. The identifiers win la, 
gc2a, and so on represent resources on the sender's display 
winch are mapped to resources win la, gc2a, and so forth on 
the receiver's display. 

Once the redraw step is finished, the share connection is 
established. From here on, the two displays are kept in 
synchronization by equivaleni X protocol being sent to each 
server. 

Connector 

The HP SharedX connector (Fig. 2) is an X Window applica- 
tion that contains all the controls that enable users to set up 
and control application sharing. Using task analysis, we 
designed the HP SharedX connector to match the user's task 
flow, thus providing intuitive controls to the complex opera- 
lion of sharing an application. Some of the usability features 
of the connector window include: 

• An address book [ Fig, 4}, accessible from the Receivers menu 
ilem in The connector window, to keep and organize common 
receivers and allow users to specify receivers by user name 
rather than machine name 

• A shared pointer (called a teleprinter), available from the 
Windows menu item in Fig, 2 T for risers to point to areas of 
shared applications during collaboration 



Fig, 4, A wiriibvv shewing I he address book. 

■ Several cues, like changing a window title so that the user 
can keep track of the windows being shared, the users re- 
ceiving shared windows, and the receivers that can send 
input to the shared application 

• Various levels of dialog information {For example, w r hen the 
user starts using HP SharedX, a Normal dialog level is set 
giving the user complete status information about the qual- 
ity of the shared application. When the user sets the dialog 
level to Experienced, only critical errors are reported,) 

• Extensive online help information, including a troubleshoot- 
ing section for diagnosing and fixing problems when sharing 
applications. 

After the first release of IIP SharedX, we gathered informa- 
tion on the product to determine major usability issues. From 
this analysis three major issues emerged; 

• The need to annotate a shared window 

• The need for a "shared whiteboard" to assist in collaboration 

• The difficulty and security implications of t lie receiver's 
granting display access to the sender for shared applications. 

The first two usability issues are addressed by the HP 
SharedX Whiteboard (see "Whiteboard: A New Component 
of HP SharedX" on page 28). The third issue is addressed by 
the IIP SharedX receiver service (described below), a pro- 
gram mat is invoked on the prospective receiver's machine 
when sharing is attempted. 

Receiver Service 

When a sharing request is made to the connector via the 
Share button, the connector software first tries to invoke the 
receiver sendee program on the receiver's computer. The 
receiver service displays a dialog box on the receiver's dis- 
play (Fig. 3\ The dialog box informs the user that the sender 
wants to share a window^ and asks for a yes or no response. 
If the user selects yes, the receiver service grants access to 
the receiver's display for sharing. 

The connector can get one of three responses from the re- 
ceiver service. The receiver can answer yes, in which case 
the connector will share the specified window. The receiver 
ran answer no, in which case the connector will display a 
dialog box informing the sender that access permission was 
denied. Lastly, the receiver service may not be present, in 
which case the connector will attempt to share with the 
receiver's machine. 
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Fig. 5- Different application sharing arc hi I ft: lures, (a) Centralized pseudoserver archil x;\-'-> I pe 1 1 I Replicated ;uvriMf-i lure £c) Sharing - 
liliran grated architecture. 



Once HP SharedX has shared windows to the receiver, it 
tells the receiver service to remove display access from the 
sender. This prevents processes other than HP SharedX on 
the sender from making unauthorized connections to the 
receiver's display, 

HP SharedX Extensions 

The HP SharedX extensions are iowdeve! routines responsi- 
ble for intercepting data streams that flow in and out of the 
X server during a sharing session. Those routines merge 
input from multiple receivers and ensure thai ihe receivers" 
displays are updated properly. 

Several groups of researchers have attempted application 

sharing in Ihe X window system environment ] These imple- 
mentations eaji be classified into four different architectures 
each with inherem strengths and weaknesses 1 (see Vm '<>. 
The main goal of sharing X applications is to ensure that the 
application and the basic X server don't have to change to 
work in a sharing environment This rem i ires some sort of 
interface mechanism between the application and the X 
server. 

By far the most popular architecture for window sharing in 
X is die centralized pseudoserver architecture (Fig. 5a). This 

architecture places a process responsible for output nmiii 
i jstiug and input merging between the shared applications 
and the X server t This architecture is the most flexible, but 

t Output multicasting >s the generation of multiple streams of requests from a single stream 
Input merging involves coalescing multiple streams of events into a single stream. 



suffers from performance problems, even hy unshared appli- 
cations, because it places a process between the application 
and the X server 

■ )ihei application sharing systems have used a replicated 
architecture for sharing windows (Fig, 5b), The replicated 
architecture runs a copy of the application for each receiver 
of the shared application and keeps these copies synchro- 
nized by sending identical input to each. Although rhis archi- 
tecture ijpiiiui/es ihe image for each receiver of the shared 
application, it has been shown to be difficult to keep the 
instances of Ihe application synchronized and nearly 
Impossible to add users to an existing sharing session. 

The sharing-capablc library (Fig, 5c) moves the output multi- 
casting and input merging found in the pseudoserver archi- 
fcecture into the library of X functions (Xlib) linked into the 
application. By moving the sharing into an existing process 
and removing the pseudoserver process, performance is 
enhanced, but applications m suHi a system cannot be sure 
of sharability, either because they have not linked with this 
special library, or because they are running on a machine in 
the network that does not have the sharing-eapable library. 

The integrated sharing architecture, which is used in HP 
SharedX, moves the output multicasting and input merging 
routines inside the sender's X server (Fig. 5dh Tins architec- 
ture ensures I hat all applications are sharing capable, while 
eliminating the pseudoserver process. 

(continued on page 29) 
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Whiteboard: A New Component of HP SharedX 



Whiteboard, a general -purpose image viewer and annotation X appticatron, is a 
new addition to HP Shared X. Whiteboard evolved from users' needs to annotate 
graphic images in shared applications. Although it is impractical to annotate 
images in live X applications because of limitations in the X Window System, 
Whiteboard allows users to share snapshots (portions! of their display and to 
annotate those snapshots. Not only is Whiteboard useful fnr adding annotation to 
computer images, it can also be used to create original images As an X applica- 
tion, Whiteboard is treated just like any other X application when it is shared in 
the HP SharedX environment. 

Some of the other features that make Whiteboard convenient powerful, and very 
functional when shared include 

• Annotation performed on an image can be erased without destroying the original 
image. 

* Any region of the user's screen can be copied and pasted into the Whiteboard 
drawing area, even if the region contains areas of different X visual types. This 
ability to copy an arbitrary region containing multiple visual types is a new 
capability for X applications 

■ When shared, Whiteboard knows when input is coming from the sender or receiver. 
Thus, it can respond differently according to the source of input This capability is 
used to ensure that receivers are restricted in what screen regions they can copy 
to the Whiteboard 

Fig. 1 shows a typical Whiteboard display, 

Annotating Images 

The main feature that differentiates Whiteboard from other drawing applications 
is the concept of erasable and unerasable layers. Maintaining two layers allows 
users to erase image annotations without affecting the image being annotated. 

When an image is loaded into Whiteboard, it is to the unerasable layer. Annotation 
can be performed in the erasable layer and then erased without destroying the 
original image. This is analogous to drawing an image on a real-world whiteboard 
in indelible rnk. annotating the image in erasable ink, and then erasing the board 
leaving the original image. This user model ts convenient in collaborative situations 
where changing just the image annotation fs desired. For convenience. Whiteboard 
allows annotation to be hidden temporarily to reveal the unerasable image. 



Copying Muftivisual Regions 

Copying a region from the screen is not as trivial as one might suspect. To an X 
programmer, using the Xlib function XCopyArea to cupy a rout window region into 
an XPixmap buffer might seem like an obvious solution. However, XCopyArea 
cannot handle cases in which the selected region includes areas of multiple visual 
types or visual types different from that of Whiteboard, the source and destination 
visual types must be the same [q use XCopyArea In more recent X displays, a 
screen can simultaneously support multiple visual types differing in depth and 
types of color maps. Therefore, it is possible to have child windows of differing 
visual types in the window hierarchy, which is not an uncommon situation 

An algorithm was developed to convert all image data in the selected region to 
the destination visual type. This algorithm involves scanning the selected region 
for all windows and parts of wrndows, coalescing those of the same visual types 
into subregions, then reading and converting each subregion to the corresponding 
subregmn of the destination pixmap (paste buffer). If any subregion in the selected 
region matches the vjsubI type of the buffer, a simple XCopyArea call is used to 
transfer the image information. Otherwise, the conversion algorithm uses functions 
m HP's Image Library to convert each subregion to the destination visual type. 

If the X server on which Whiteboard is running supports deeper visual types than 
the default, Whiteboard keeps the paste buffer in the deepest visual type available, 
even though Whiteboard rs running in the default (shallower) visual type. This 
technique maintains the buffer contents at the highest possible color fidelity, so 
that when a scaled paste is done, making the image larger, the resulting image 
does not contain pronounced dither patterns 

Recognizing the Source of User Input 

Whiteboard is the first application that is able to detect the source of user input 
when the program is shared Whiteboard uses a feature of the HP SharedX exten- 
sions to the X server on the sender to examine events and determine the source of 
input. Based on whether the sender or receiver generates the input, Whiteboard 
performs a different operation when the Copy Region button is pressed. When the 
sender presses the Copy Region button, Whiteboard allows the oser to select a 
region on the sender's screen to copy. However, for security reasons a receiver 
should not be able to copy the sender's whole display Instead, a Copy Region 
operation by the receiver confines the function to the Whiteboard drawing area. 




Fig. 1. A typical Whiteboard display The 
white arrow with the circle on The end antf ThE 
text illustrate a typical annotation. The picture 
on The fight, wheh shows a EOometMn portion 
nf the main image, is an example Df copying 
and pasting a portion of an image into the 
Whiteboard 
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ideally. Whiteboard should perform the espy from the display from which input is 
i Unfortunately, Because Whiteboard does not have a direct connection to 
me receiver's display whence application is shared, no copying operations can be 
initiated from the receivers screen Although me implemented Copy flegion function 
does not present the most ideal solution, it does maintain complete functionality 
for the sendee while providing the receiver with a reasonable substitute for the 
copy operation 



The advantages of the IIP SharedX extension architecture 

(integrated sharing architecture) include: 

• Any X application can be shared at any time 

• l nshared applications do not suffer a performance penalty 

• Sharing performance is optimized because state information 
about the X server is directly accessible to the sharing 
mechanism. (Other implementations require the sharing 
mechanism to query the X server state over the network, 
slowing down the sharing process 

The main disadvantage of the HP SharedX architecture is the 
need to modify the X server, which requires access to the 
source code for the X server. I sing tlte sharing- library ap- 
proach, an application Can he Linked with a sharing-canable 
Xlih and can then be run with any standard X server. 

Although these architectures for sharing applications differ, 
the basics of sharing an application are the same for each 

I wit It the exception of I he replicated architecture). These 
basics include making instances of windows on receivers* 
displays, echoing the rendering requests of an application to 
each receiver, matching resources on the sender machine 
with those on the receiving machines, and merging input 
events from the multiple X servers into a single stream and 
returning the information back to the application. The fol- 
lowing sections give a detailed look at how IIP SliaredX 
deals with some of these issues in sharing applications. 

Limitations of [IF SharedX 

Applications are displayed on HP workstations in one of two 

ways. They are either displayed via the X server using X 
protocol, or displayed directly using direct hardware access 

I I )MA )/' i)H A allows applications to bypass the X server to 
render graphics on the display. Since IIP SharedX operates 
by retransmitting X protocol to the receivers display, appli- 
cations based on X can be shared, while DIIA programs can- 
nol be shared directly. The static images from DMA applica- 
tions can be shared by copying their windows into the 
Whiteboard application described on page 28; 

Programs thai render through the DIIA mechanism include 
I hose thai use Ihe Slarktse graphics package or PKXt pro- 
gramming interface. However, the programming interface 
does not make the final determination of the rendering path. 
For example, Starbase programs ran be run with a graphics 
driver that emits X protocol instead of using DMA. While 
there is usually some performance penalty for using these 
drivers, it does allow the application to he shared 

Even if an application is based on X, it may not share per- 
fectly For example, the audio application of UP MPou> r 
uses X protocol to display its control panel but interacis 
with the audio server to generate sound. Even though the 
control panel shares properly, when the receiver presses the 

t PFX .1- ih ■■■ h .iiiijemenrs to ihe X protocol. 
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Fig. 6, An MP SharedX configuration in which output fmni a shared 

HI is not echoed on the receiver In this case the output 
going to the audio server which knows nothing about the receiver, 

play button, the audio is played only on the senders audio 
server (see fig. 6) 

Another example of applications that do not share perfectly 
are I hose applications thai use X extensions. The X exten- 
sion is a mechanism for extending the capability of the X 
Window System While the core X protocol is standard 
among all X servers. X extensions vary among X server im- 
plemer Hal inns HP SharedX <mly ret ratisi nils core X protocol, 
so applications that use X extensions wilt have limitations 
when shared. For example, if an application uses input de- 
\ ices other than the keyboard and mouse via the X input 
extension t tt the receiver will see a copy of the window but 
will not be able to interact with the application with these 
additional input devices. 

There are parts of die coane X protocol that HP SharedX can- 
not handle properly. One example is The X mechanism for 
cut and paste. This mechanism uses a standard interprocess 
messaging system for transferring data from one X program 
in another, However, a receiver cannot cut and paste be- 
tween a shared application and one On the local machine 
The two applications cannot communicate since they are 
not connected directly to the same X server. 

Establishing and Maintaining Connect ions 
When a share request is made to a receiver IIP SharedX must 
first establish an X connection to the receivers X server. It is 
over this connection that MP SharedX will manage the 
shared windows, retransmit rendering requests, and get re- 
ceiver input. Hie display connection is made using the X 
library (Xlih). 

Xiib is the client-side library of functions used by all X appli 
cations. These functions create the protocol requests lhai 

r i Tlie X input Rxtenshnn allows applications to receive input from input devices such as graphics 
labors knobboKe*. buna 1 1 on 
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become the X protocol packets sent over the display con- 
nection to the X server lo request creation of windows, 
drawing to those windows, and so on. Although the HP 
SharedX extension is in the sender's X server, it communi- 
cates with the receiver's X sewer using Xlib. This makes the 
sender's X server appear to the receiver's X server the same 
as any other X client. 

The IIP SharedX extension, however, has some requirements 
that are different from other X clients, ®d we made some 
changes to Xlib to accommodate these requirements. The 
first, change we made to Xlib was to create a mechanism to 
recover from broken display connections. In X, programs 
that lose their connection to the X server normally print an 
error message and exit. For most X programs, their one con- 
nection to the X server is their lifeblood, and if it is broken, 
they may as well terminate. The sender's X server still has 
plenty to do if it loses a sharing connection, and thus it 
should definitely not terminate, Xlib calls a user-specified 
routine, XIOErrorHandter T when a display connection is broken. 
In HP SharedX's version of XIOErrorHandler, the routine cleans 
up data structures related to the broken display connection, 
sends a notification to the IIP SharedX user interface, and 
jumps back to a location inside the X server to conlinue 
processing, 

A similar problem occurs when the remote X server is not 
responding. This can bappen for a variety of reasons such as 
that another program may have taken exclusive access fcq 
the X server, the network between the tw r o computers may 
be very busy, or the receiver's X server may be busy han- 
dling requests from other clients. In any case, X programs 
wail indefinitely for requests to be serviced before proceed- 
ing, which is not the desired behavior for the senders X 
server. Therefore, IIP SharedX has added a timeout handler 
to Xhb that allows the senders X server to recover from a 
nonresponsive receiver. After 30 seconds n\' wail i rig oil a 
receiver's X server, HP SharedX closes the display connec- 
tion and notifies the sender that the receiver's system is not 
responding. 

The final change we made to Xlib handles failures to estab- 
lish an X (display) connection. Normally when a display 
connection fails, the program is not given a reason for the 
failure, A mechanism was added to extract the reason for 
< lisp lay connection failure from Xlib and to return that infor- 
mation to the user interface. This information allow r s the 
user to diagnose problems more easily when attempting to 
share windows, 

Managing Shared Windows 

When users share an application, they usually have a clear 
idea of what constitutes the application arid what set of win- 
dows should be shared. Most applications consist of a single 
program wdth a single connection to the X server. For these 
programs, it is easy for HP SharedX to share the right win- 
dows. However, an application can consist of more than one 
program (e.g., IIP SoftBench), or a single program can dis- 
play several windows that shouM not be grouped together 
(c.g. T the HP VUE file manager can display multiple windows, 
each looking at a different directory). A user of the HP VUE 
file manager usually wants just one window r to be shared, 
while a user of HP SoftBench may expect the debugger to be 
shared along with the static analyzer. 



From the point of view of the X server, windows partake of 
two relationships. One is a parent-child relationship, which 
defines a window tree with all windows as descent! ants of 
the root window. The other relationship is that in which 
each window is owned by a display connection. Each win- 
dow is uniquely identified by its window identifier, a 32-bit 
number in which seven of the bits are the same for windows 
owned by the same client. These seven bits are called the 
resource base. 

Applications typically consist of one or more top-level win- 
dows in which applications display information. Because 
windows are relatively inexpensive to create, they are used 
extensively inside an application s top-level window for 
everything from drawing areas to buttons and menus. 

When the user selects an application to share, HP SharedX 
must select a group of windows that best represent the appli- 
cation to send to the receiver's display. IIP SharedX makes 
two assumptions: all top-level windows belonging to a single 
client Connection (i.e., having \\w same resource base) belong 
to a single application, and ail child windows of a shared top- 
level window should be shared with that top-level window. 

Using these assumptions, if the sender shares an HP VUE 
file manager window, IIP SharedX will send to a receiver all 
tile manager windows. Users have the option of selecting 
Sh3 re Alone from a pull-down menu, but they could easily 
forget which applications to do this for. However, HP 
SharedX can be configured to respond differently to the 
main Share button for different applications. For many appli- 
cations, HP SharedX is shipped p reconfigured to share only 
the applications selected top-level window and its children. 

The other problem mentioned above, that of multiple pro- 
grams tli at should be shared together, has not been ad- 
dressed directly. While application developers could use the 
IIP SharedX command line interface to tie their applications 
together, HP SharedX does not provide a simple mechanism 
for grouping windows from different programs, "Typically, 
for these applications the user must manually share all the 
desired windows. 

Input Management 

HP SharedX allows both the sender and the receivers of a 
shared application to interact with an application. In X, 
application input consists of events from the users input 
devices and queries that the application makes about these 
devices. For example, the application can query the position 
of the mouse cursor, which, if the application Ls shared, has 
as many values as there are viewers of the application. 

Most application-sharing systems implement one of two 
input merging policies: floor passing or free-for-all. The floor- 
passing scheme allows one user at a time to input to the 
application, with the choice of the user who has the floor 
manually controlled by a moderator. The floor-passing 
scheme ensures thai input is not mixed from multiple users, 
but it requires explicit user action to change the input floor. 
The free-for-all policy allows anyone to input without explirii 
action, but it is prone to intermixed input from multiple users. 

The HP SharedX input model, called dynamic floor passing, 
is a hybrid of these two methods. In this scheme, only one 
user at a time can give input to the shared application. Thus, 
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user input does not become mtermixecL However, input may 
change among users dynamically without explicit action, bul 
only after a specific period of inactivity by the current user 
giving input. 

In addition to answering the problem of intermixed input, 
dynamic floor passing solves the problem of input queries. 
This meLhod always n turns the state of the user's input 
devices currently or most recently interacting with the 
application, 

The final challenge of handling input from multiple users is 
translating the actual input event thai occurred on a receiver 
into an event that could have occurred on the sender. Trans- 
lating a window identifier is trivial because HP SharedX 
maintains a mapping of which receiver windows correspond 
to which sender windows, Translating the keycodes in the 
event message is more difficult 

The keyeode specified in an event is an index into a mapping 
table of logical key symbols that can vary from one X server 
to another For example. Offcfc server can map keyeode 52 to 
the letter V, while another server can map the same key- 
eode to the letter "z w . The keyeode mapping table is loaded 
into the shared application when the display connection is 
made, but the mapping can be changed dynamically 

When an event with a kt^ycode is received by HP SharedX 
from a receiver, it is translated into a key symbol based on 
the current mapping for the receiver's X server. HP SharedX 
searches the sender's keyboard mapping to see if any key- 
code matches that same key symbol. If it does, the matching 
keyeode is relumed in an input event to (he application. If 
no corresponding keyeode on the sender's machine exists, 
the key event is discarded since no logical keyeode can he 
sent to the application. 

The How diagram in Fig. 7 shows the operation of the input 
merging routine, including dynamic floor passing control 
and event-code translation. 

Allocating Display Resources and Rendering 

HP SharedX uses a *lazy" allocation scheme for display re- 
sources such as colors, pixmaps, graphics contexts, and 
fonts. To minimize initial sharing Lime and the impart oa the 
recei%ing machine, display resources are allocated only when 
needed for a rendering request. For example, a shared appli- 
cation may allocate a large pixmap that is only <iisplayed for 
some error condition, if I hat error condition never occurs 
during the sharing session, it would be a waste of time 
and resources to make an instance of the pixmap on the 
receiver's machine. 

Once allocated, the display resource mapping is maintained 
su that hit ure requests lor that same display resource are 
satisfied without contacting the receiving X server For ex- 
ample, if an application requests a line he drawn to a shared 
window, HP SharedX performs the following procedure: 

draw the line to the locat display: 

tor each remote instance of the window 

begin 

if a remote instance of the graphic context has already 
been allocated, 

use that instance, 
else 
allocate a new remote graphic context and map it to 
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Fig* 1. flowchart for the 111* SharedX input merging routin- 

the local graphic context; 
draw a line to the window instance with the graphic 
context instance; 
end; 

When the allocation of a display resource tails, HP SharedX 

ral means to recover, In the case or pixmaps, HP 
SharedX continues operation of the application without the 
use of that image and notifies the user oft his situation. In 
other cases, HP SharedX will substitute other display re- 
sources for the ones it cannot allocate. The next two sections 
provide detailed examples oft wo display resources HP 
SharedX will gracefully degrade: colors and fonts, 

Man agin j* Colors 

The management of display resources such as graphic 

contexts and windows in ill 1 SharedX is fairly straighifor 

ward compared to the management of colors. The goal of 
displaying identical images on all shared windows requires 
n tapping colors from tin sender's display lo the receiver's 
display and degrading the colors gracefully if the exact 
colors me unavailable. 
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The term pixel refers to the number that rt'p resents a color 
value. The pixel can be one of two types: read-Only, which 
represents a color that does not change and can therefore 
be accessed by multiple programs simultaneously, or read/ 
write, which can be changed and is exclusively used by a 
single application. 

Pixels are converted to colors either by using the pixel as an 
index into a color map (a look-up table) or by treating 1 lie 
pixel as a representation of the color itself The interpreta- 
tion of the pixel is based on the visual type,! of which there 
are six in the X window system. Three of I liese allow X pro- 
grams to allocate read/write cells (grayscale, pseudo colon 
and direct color), while the other three provide a fixed set of 
colors (sialic gray, static color, and true color). 

To divide the six visual types another way, four of them 
(static gray, grayscale, static color, and pseudo color) use a 
single color map to map a pixel into a gray value or an RGB 
triplet (Figs. 8a and St>)« These displays typically use between 
one and eight planes, so their color maps typically store 
between 2 and 256 color values. Another visual type t direct 
color, uses Three color maps, one each For red. green, and 
blue. The pixel is decomposed into three indexes for look-up 
in the three color maps (see rig. 8c), The last, true color, 
decomposes the pixel directly into red r green, and blue values 

t Color map capability jsee glossary on page 26) 



(see Fig. 8d). TVue color and din-H color typically use either 
12 or 24 planes, yielding %096 or 16,777,216 colors, 

Our color mapping solution addresses two questions. Given 
the senders and receivers visual types, and the sizes of their 
color maps (number of different colors available): 

■ How are the available colors used to best advantage? 

i How is color mapping maintained? 

Using the Best Colors Available. The key to color matching is 
always to have a color thai is close enough if the exact color 
is unavailable. If the receivers color display system is static, 
supporting only read-only colors, the solution is simple: map 
each sender color into the closest receiver color. For receiv- 
ers with dynamic color systems that support read/write col- 
ors, a color ramp is created. The color ramp contains a sel 
of colors evenly distributed throughout the RGB color space, 
a three-dimensional Space tie lined hy axes of red, green, and 
blue values (see Fig, 9), The benefit of the ramp is that any 
color matches a ramp color within some maxhmim color 
difference in the color space. However; the maximum color 
difference may still be larger ihan is desirable, so the ramp 
is a fallback if an exact color match cannot be allocated. 

A color ramp array and the values for Ore receiver's color 
map are created when the display connection is made to the 
receiver for sharing, Kig. 10 shows an example of a color 
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Fig, 8, Four representations for the color magenta, (a) The read-only gray level (statu: gray or grayscale ) rtjutvalents for mag* : 
(b) Read-only Static color or pseudo color representations. U0 Direct color representation of magenta. The pixel is split into indexes into 
the color map. (d) True color representation. The pixel value is split into parts, and each part is scab N " ■ ■ I fee \ ahies for t lie different 

shades of rod, green, and blue for magenta. 
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Fig. 9. A three-dimensional ret . n of the color ramp for an 

8-bit color display with four sh: r shades of red t and 
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ramp array that contains pointers to the color map on the 
receiver. The values in the rotor map are determined from 
the three-dimensiona] color ramp mentioned above. As each 
entry is allocated in the receiver's color map* the index to 
that entry is sent back to the sender and placed into the ramp 
array table, creating a table of indexes into the reeei 
color map. 

The size of the color ramp depends on the size and type of 
the destination visual type, For grayscale visual types, a 
grayscale ramp of up to 16 values is allocated. For direct 
color visuals, up to Hi levels of red, green, and him ■ for a 
Total of 1,096 distinct color values are allocate!!. In both of 
these visual types, 16 levels provide enough resolution to 
ensure a good color match without using excessive color 
map entries. The ramp used for eight-plane pseud o color 
consists of all combinations of four evenly spaced values of 
red. eighl values of green, and four values of blue, for a total 
Of I by 8 by 4 = 128 colors. The ramp takes up half of the 
available colors in an eight-plane color map. 
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Fig. 11, A I v. ■■ m Jimertsional representation of the color Spa 
by the color-matching algorithm 

Eight-plane pseudo color visual types are (lie most common 
and most difficult type to deal with since not enough colors 
exist to cover the color space adequately with a ramp. To 
compensate for large color errors, HP SharedX judiciously 
uses the remaining color cells available in addition to the 
ramp. For any given color, the following color-matching 
algorithm is used to map the sender's colors onto colors on 
the receiver: 

i. If the X application on the sender allocated the color as 
read/write, then attempt to allocate a matching read/ write 
color on the receiver. A read/write color is needed since the 
application may change the color of the allocated pixel at 
some later time and, to maintain color accuracy, the 
receiver's matching color must be changed as well 

2. If the application allocated a read-only color or if the 
above allocation failed, find the closest color from the ramp 
or a previously allocated read-only color. If thai color is 
close enough to the desired color, use it as the match. 

:l If the closest read-only color is not close enough, try m 
allocate a new read-only color, [f this succeeds, add the 

color to the list of allocated read-only colors and return the 
new pixel as the match. 

4. If the read-only color could not be allocated, use the 
closest pixel from step 2 since ii is the best available mat* li. 
Nidify I he user that the colors do not match exactly, 

Fig. 1 1 shows a two-diniensional representation of the color 
space given in Fig. 9. Each circle encompasses colors that 
are close enough to a particular color ramp value (repre- 
sented by the point in the middle of each circle]. Each of the 
points represents a read-only color that has already beet) 
allocated on the receivers X server. 

The color-matclung algorithm first checks to see if a color is 
close enough to an already allocated color. Point A in Fig. 11 
is close enough so another cell is not allocated (step 2 in 
algorithm). Thus, for point A, 2/3 red, (V7 green, and some 
value for blue is used. 

Point B in Fig. 1 1 i> nut close enough to any allocated color, 
so a color is allocated and point B is added to the list of 
available colors (step 3 of the algorithm I If B cannot be 
allocated in Hie color map, the closest color is selected that 
has already been allocated, although technically it is not 
close enough (step 4 of algorithm ). 
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The difference between the desired color and the candidate 
color is measured as the sum of squares; 

diff = (desired^red - aetual^red) 2 + 

(desired j^reen - aetual^green )- + 
( desired_blue - actuaLblue) 2 

The color with the minimum difference is the closest color. A 
close enough threshold was determined empirically to opti- 
mize the accuracy of color images while minimizing the num- 
ber of receiver color cells used. Since images lend Co have 
color themes (i.e., the colors are clustered in a few regions 
of the color space), a fairly high degree of color accuracy 
can be obtained without excessive demand for color cells. 

Private Color l/laps. An X display has a default, shared color 
map that most applications use. If an application needs 
more colors than are available in the default color map, it 
can create and use a private color map over which it has 
complete control. When an application using a private color 
map has its window focused, that applications color map is 
installed (copied into the display hardware) by the X win- 
dow manager. On displays that support only one color map 
in hardware (most of the low-end displays), everything on 
the entire screen is displayed using the installed color map. 
When a private color map is installed, ail applications using 
the default color map take on random colors. As soon as an 
application using the default color map gains the focus, the 
default color map is reinstalled, and the application with the 
private color map will have random colors. As I he current 
color map switches back and forth from default to private, 
the user sees color flashing. The user typically prefers to 
display shared windows with the default color map to avoid 
this irritation. 

When a window 7 is shared to receivers wilh display types 
that have read/write color maps, a color ramp is created on 
the receivers X display. The ramp is created in the default 
color map to reduce the probability of color flashing. If the 
desired ramp cannot fit in the default color map, it is placed 
in a private color map, 

The system user interface is usually the first process to 
allocate pixels, and the pixels with the smallest indexes are 
allocated first. When a private color map is used, HP SharedX 
copies some of the lower pixel values from the default color 
map into live private color map. This way, when X switches 
betw r een the two color reaps, the i .-ulurs used by the system 
user interface do not flash. The number of pixels copied is 
optimized to reduce color flashing while leaving color cells 
for later allocation. 

Keeping Track of Pixel Mapping. To minimize the number of 
times the color matching algorithm is executed, a mapping 
of previously matched pixels is maintained. Different map- 
ping methods are used depending on the range of possible 
sender color values. For small ranges (up to 256 different 
colors) a simple array is used, in which: 

receiver_pixel = map [sender_pixelj 

When the sender is a 24-plane display, this approach would 
require 4S megabytes of memory; so a more mernory^fGcient 
mapping scheme is needed. Since the goal is to produce 
close colors for the receiver rather than exact color matches, 
resolution of the sender i olor is reduced before applying (he 
color mapping. Red, green, and blue values of the Color are 



reduced to four bits rather than eight bits for each plane, 
win* :U results in L6 (2*) levels of each. Thus, the total num- 
ber of possible color values is 4()96 { IG 3 ), a reasonable size 
for a mapping array. If color!) is a function that returns the 
RGB values of a pixel, and cruncht) is a function that converts 
an RGB triplet to a number in the range 0. ..4095 (four bits 
per pixel ), then the mapping is as follows: 

receiver_pixel = map [crunch (color (sender_pixelj|] 

The result of this mapping is that all colors close to a mapped 
color are mapped with that colon This method, called color- 
zone mapping, gives fast performance and adequate color 
inai rhitig, wiule keeping memory use fairly small 

Matching Fonts 

The fonts in which applications display text can be specified 
by the user in the X Window System. Prom the set. of fonts 
supported by the X server, the user selects a font thai is 
aesthetically pleasing. Since there are no standard fonts in 
X, each X server can support a different set of fonts, 

To maintain consistency between the sender and receiver of 
a shared application, it is important that text be displayed in 
ii Similar font on the receivers display. HP SharedX employs 
a font matching algorithm to ensure a close font match, 

Fonts in X have both a name and characteristics. A font can 
be loaded by specifying either its name or its characteristics 
using the X Logical Font Description (XLFD) format, IIP 
SharedX first tries to match the font by name since it is un- 
likely that fonts \\ ith the same name differ, if the font with 
the same name is unavailable on the receiver's X server, 
fonts are matched by I heir characteristics. 

The XLFD description defines 13 characteristics of a font 
such as its size, character set, weight, slant, and style. When 
matching fonts for the purpose of sharing art application, 
some of these characteristics are more important than others 
in choosing the font with the closest characteristics. 

HP SharedX obtains a list of all XLFD type fonts from the 
receivers X server at display connection time. When a font 
march is needed, the source fonts characteristics are com- 
pared lo those available on the receivers X server. A 
weighted sum of differences of the characterise 's is calcu- 
lated and the font with the minimum difference is considered 
the closest match. 

The weighting of characteristics was determined through a 
combination of intuition and observation. With the excep- 
tion of character set, discussed below, it seems clear that 
size is the most important criterion, with width taking prece- 
dence over height. This is partly because many X applica- 
tions write text in two different ways. One w r ay is to pass a 
whole string of characters to the server and lei it determine 
the local inn of each character based on its knowledge of the 
font. The other way is for the program to control the spacing 
arid send one character at a time to the X server. The pro- 
gram must then know ahout the character widths for the 
font in use. In this method, the program has no knowledge 
that the receiver may be using a different font with different 
spacings. and characters may overlap or be widely spaced 
for their size. If the first method is used, the receiver's X 
server will correctly space the characters for the font in use, 
but the positions of characters within the window will be 
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incorrect- If both methods are used, as they are in terminal 
emulators, the receiver is faced with a messy mixture of 
incorrect - . - ;md characters in incorrect positions. 

Another important factor with respect to spacing is whether 
a font is proportional or monospaced Proportional fonts use 
different widths for different characters, while a mono- 
spaced font uses the same space for all characters. In most 
cases, it is better to match a monospaced font to another 
monospaced font, even if they are of slightly different size, 
tlian to match it with a proportional Font of thi ize. 

Likewise, matching a proportional font with another propor- 
tional font tends to give the best appearance, and if the type- 
faces aire similar, the chance is high that specific chara< 
widths will he similar. 

The issue of character sets is an easy one for an English 
speaking person to ignore. Almost all fonts have identical 
characters in the range of characters most often used (the 
ASi II Characters) numbered 32 to 127. The differences lie 
mainly in the upper range, the characters numbered 128 to 
ind beyond. This is where characters with special 
tits, used in most European languages, are found. If 
accented characters ape used, the difference in character 
Is very important 

This issue becomes more important when character sets for 
pictograms or entirely different alphabets arc used. If the 
character set does not match, the receiver is given meaning- 
less garbage. But what constitutes a match? Does the name 
of the character set have to match exactly, or are there more 
or less equivalent character sets that have different names? 
These issues have not been addressed in the rurrenl font 
matching algorithm. For HP SharedX to work acceptably 
with these types of Characters, 11 is best m have the same 
font on sender and receiver machines. 

Performance 

The performance of IIP SharedX depends on the character- 
islics of the network connection, the performance of the 
workstations involved, the application being shared, and the 
operations performed with the application. There are Three 
networking factors that affect performance; network Speed 
or band v* idth, line delays, and network Load. Increase! I load 
js o Highly equivalent to decreased bandwidth. Performance 
increases directly with reetwoik bandwidth, up to a limit of 
about 500 kbifcs/s tor an unloaded network. Beyond that, 
other factors limit performance, Line delays are of greater 
impt ntanee when sharing over a wide area network f WAN }. 
sen update times increase proportionally to line delays. 

Given a network with reasonable bandwidth, HP SharedX 
performance will be greatly affected by the performance ol 
the et iiiipiiters involved in the sharing, especially the send- 
ing machine. When users have a choice of who sends and 
wtio revives, the person with the faster machine should be 
the sen,! 

Applications vary widely in how they make use of X. Kor 
example, an application receives an expose event from the 
X server, indicating thai some portion of a window hasjusl 
become visible and therefore needs redrawing, Some appli 
rations redraw the entire window, wlule others are more 
efficient and only repaint the portion thai is exposed \ 
uurrl processing application may update the entire window 



every time die user types a letter. While this scheme works 
acceptably when not sharing, this application is nearly 
unusable when shared. 

If application windows can be resized, the sender can im- 
prove performance by making windows smaller. Also, users 
often come to recognize slow operations. If resizing can be 
done before starting the sharing session, there will be less 
demand on the network. If the application is still boo slow 
when shared, the iii take snapshots of it with the 

Whiteboard and share the Whiteboard. 

Lazy allocation of resources in HP SharedX affects perfor- 
mance in some interesting m a\ % 1 < >r example, the White- 
board uses two large pixmaps for the drawing area, one for 
the erasable layer and one for the unerasable layer. The 
erasable pixmap is allocated immediately when the Whirr- 
board is shared. The other, however, is not used until the. 
user does an erase operation. The user may be typing some 
text into the drawing and then hit rtu backspace key. At that 
point, the Whiteboard and all other X programs on the send- 
er's display "freeze" while the unerasable pixmap is created 
on the receivers X server. 

When more than one receiver is involved in a sharing ses- 
sion, the method of connection becomes important inhere 
is one receiver, and the parties involved want to add a sec- 
ond, either the sender or die receiver can share to the new 
person. The firsl receiver sharing to the second receiver is 
called daisy chaining. The sender sharing to more than one 
receiver is called fanning out. With the right combination of 
daisy chaining and fanning out, an application can be shared 
to a large number of people. 

Determining an optimal configuration for one-to-mam 
sharing is more complex when the computers vary in perfor- 
mance or when the network links between the parties vary. 
Some general rules for optimizing performance are: 

* The fastest machines should be daisy chaining, and slow 
machines should all be leaves in the sharing Uve. 

• When some of the iv< eivcrs are connected by a LAN, while 
others can only be reached over a WAN, tire number of WAN 
connections should be minimized. 

For example, if a sender in Colorado is sharing a window to 
ii\e receivers in NVu York and three receivers in California, 
it is most efficient for the sender to share the window to die 

fastest receiver in New York and ihr Eastesl receiver in 

California and have Ihose receivers share to others on tin 
same local network. 

Conclusions 

The implement at ton of HP SharedX presented several prob- 
lems. First and foremost, since Ibis type of technology is 
new, no foundation of past experience was available to build 
upon, especially when it came to designing the HP Sham IX 
user interface. The nsrr interface design challenges Were 
solved by applying human factors design techniques, includ- 
ing user task analysis and human factors testing. The HI 1 
SharedX extension presented a totally different challenge, 
including handling input from multiple sources in a sane 
manner and applying X protocol customized for a machine 
oTone type and [napping it to machines of very different 
types, The HP SharedX extension challenges were met by 
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understanding the nature of the X window .system and grace- 
fully degrading the display linage when receiver display re- 
sources do not match those of the senders display. Although 
there are no perfect answers to any of these challenges, the 
value of IIP SharedX far outweighs its limitations, 
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Imaging Services in a Multimedia 
Environment 



Image manipulation tools, compression and decompression functions, 
picture quality adjustment techniques, and support for industry standards 
are some of the features included in the HP Image Library. 

by Andrew ftfunro and Ahmad H. Shekarabi 



Qjp f/\lX*-sy stem-based computers words are the tradi- 
tional means of communication whether the user is creating 
a business report or presentation, writing a functional speci- 
fication, or sending electronic mail While the topic might 
benefit from some \isual content, the user usually finds it 
easier to just use words. 

Unfortunately, words may not be enough. The user could be 
describing CAD graphics that remote colleagues need to see. 
Perhaps, the user is an insurance adjuster who is sending a 
report to the home office that describes photographs of dam- 
aged property. Another user may be describing the appear- 
ance of a computer screen that a customer support engineer 
needs to see. 

Without imaging capabilities on the computer, the user may 
resort to n on computer means, such as the postal service, to 
send images. 

This article describes the major parts of the HP imaging 

solution, how ii . -\ laract eristics required of an 

imaging system, and its application to IIP MPower. 

Image Piles 

Image files contain rompuler graphics and digital records of 
physical objects, such as photographs, pages from books, 
and faxes. The images of these objects are represented as 
collections of bits called pixels. 

Image data comes from several sources including screen 
captures, video frames, and external devices such as scan- 
ners, video recorders, or fax machines. Once the image data 
is collected in a file it can be displayed, modified and saved, 
or printed. 

The data in image files is stored in different formats. These 
image formats are more commonly called image types. The 
most popular image file format is called tagged image file 
format, or TIFF. The following are some ol types of images 
Stored in TIFF files These imam- types are listed in order of 
image quality — from a simple monochrome lu the highest- 
quality colot. 

* Bitonal. Bi tonal images contain pixels with two levels — 
black and White — but they can be displayed using any two 
colors, Each pixel lakes one bit Bitonal images are fre- 
quently referred to as monochrome images. They often con- 
tain text, such as a page of a fax. 

• Grayscale, Grayscale images contain pixels thai identify 
le%'els of gray, from black to white. Grayscale images are 



sometimes also referred to as monochrome images. They 
are often user! for images of scanned photographs. 
Palette, Palette images contain pixels that index into a color 
map containing the red, green, and blue values For the pixel 
The color map has three contiguous sections; red. gr 
and hlue, each with 256 16-bit entries. The color of a pixel is 
determined by using the pixel value as an index into each of 
the red, green, and blue sections 10 obtain the desired color. 
This is the lowest-quality color image and is also called a 
pseudo color image, a type commonly used for computer- 
generated images. 

RGB, An KGB image contains pixels with three samples: 
red, green, and blue. Each sample identifies a level of thai 
primary color. This is a good-quality color image type that is 
typically used for photographs. RttB format provides better 
pin are quality than the palette format because RGB pro- 
vides 2~ 4 color variations for images, whereas the palette 
provides 2 y color variations for images. 
YCbCr. A YCbCr image contains pixels with three samp! 
in the order Y T Cb T ("r, (, Y( '!»< r images are often incorrectly 
termed YUV images.) The V sample is ■ ailed the luminance 
sample; it represents the gray level of each pixel. Cb and Cr 
are called the chrominance samples. Together with Y. they 
represent the color of each pixel. An RGB image can have 
the same high quality as a YCbCr image, but a Yi ftrf r image 
often requires less disk space. 

These image types are supported by the image libraries 
described in this article. 

Using Image Files 

In trying to provide a software alternative that makes using 

images as easy as using text an application developer is 

usually fared with the following issues from potential 

customers. 

I don'1 have enough disk space to store images. 

If I compress my images, won't they become slow u> display'.' 

1 1< m can I clearly display photographs when the screens 

resolution is uuk £8$ of the photograph s resolution? 

Aren't there too many computer formats of image files to 

deal with? 

Because of these issues, Hewlett-Packard took a compre- 
hensive look at. the Imaging requirements of end users and 
application programmers. Imoni ibis Investigation, the image 
library project learn determined that an imaging solution 
with the following characteristics would be needed to fulfill 
the needs of both application developers and end users: 
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Fig, 1, Ttie four types of iinages the HP Imago Library can read, 
write, atKl display. 

• Support for industry-standard image file formats 

• Minimum disk space* requirements for storing images 

• Fast, high-quality display of compressed and uncompressed 
images 

• Basic image manipulation, such as rotating and cropping 

• Extensibility to allow programmers to add custom image 
functions and custom image file formats. 

The solution we created to help fulfill these needs has three 
parts: libraries of image functions built on the X Window 
System, end-user tools built on these libraries, and an image 
developer's kit with an extensible appli cation interface, 

HP Image Libraries 

To make imaging functionality a standard capability on HP 
9000 Series 700 workstations and Seiies 800 multiuser sys- 
tems, the image team decided to create two libraries and 
build them into the standard run-time environment , These 
two libraries, the image library and the extensible file sup- 
po7l library contain high-level functions thai C programs 
can use to access and manipulate images. These two libraries 
are collet] ively called the HP Image Library With the HP Im- 
age Lib rai y I u n i '■ I i o n s , aj >p I i cat i ons can read and write im- 
ages that exist in four forms: 

• A file image. This is an image in a single or multipage file 
(e.g., a file containing the image of a fax cover page pins 
one or more other fax pages). 

• A client image. This is an image in memory that is created 
and managed by a client application separately from Ihe HP 
Image Library functions. 

• An internal image. This is an image in memory that is 
created and managed by the HP Image Library functions, 

• X Drawable. An X window 1 image such as art HP terminal 
window or an X pixmap such as an iron symbol 

Fig. 1 summarizes the relationship between these four forms 
of images and the HP Image Library. 

While the image library functions support TIFF image files, 
the extensible file support library addresses support of non- 
TIFF image files, The extensible file support functions oper- 
ate on image files in an object-oriented approach, indepen- 
dently of the file type. Therefore, if the programmer defines 
a new type of image file, the existing client programs 
continue to work on the image file without mortification. 
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TIFF Files 





HP Image Library 

Fig. 2, The image library and extensible ille support library in the 

clienty.se rver archil <><1 ur ■■ ■ 

All hough the extensible file support library also supports 
TIFF. that, support is not as extensive as the image library 
support of TIFF. The extensible file support, or TIFF files 
enables applications to treat TIFT files as merely another 
image file. 

The HP Image Library runs on the HP-UX* operating system 
and uses the X Window System to display images (see Fig. 2). 
Because the image functionality is layered on standard X, 
the user gains all of the client/server advantages of X. 

Using Pipes to Access Images 

7b simplify the programming task, the image team designed 
the image library and the extensible file support functions 
around the concept of an image pipe. An image pipe is a 
series of calls to functions, beginning with a producer (a 
function that reads an image from a source such as an image 
file) and ending with a consumer (a function thai writes an 
image to a destination such as a display). Fig. 3 shows the 
steps in a sample image pipe. 

While only one producer and usually only one consumer 
function are allowed per pipe, I he pipe can also contain 
functions that manipulate Ihe image. These filter- functions 
perform operations such as decompressing, scaling, rotating, 
or converting the image. 



Producer 



Filter 



Filter 



Filler 



Consumer 




Fig. 3. The steps m an image pipeline. 
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A producer can access any form of image (Xwd, file Image, 
client image, or internal image). Filters operate on the image 
data supplied by the producer The consumer receives the 
filtered image and writes il to the display, a file, or an internal 
or client imaj 

When the pipe is executed, it processes the image in hori- 
zontal slices, which are called strips sing strips re- 
quires smaller buffers herween filters and less memory than 
processing an entire image. Because processing strips can 
be located in cache memory, image processing performance 
benefits. For complex image processing, images begin ti - 
appear quickly because there is no need to wait for the 
entire image to be processed before disp laying it- 
Industry Standard File Types 

Since there are several sources For images (e.g., scanners, 
PCs, fax machines* LAN, and so on) multiple types of image 
Big formats have emerged. 

To enable applications to handle these different file types, 
the HP Image Library provides reading and writing support 
for the image file types listed in Table I. 

The following are definitions for file types not defined earlier. 

• LZW. Lempel-Ziv and Welch compression format (described 
below) 

• Xwd, X window (an image created by storing the contents 
of an X window in a file) 

» GIF, A common format for palette images 

• JPK< r, -luinf Photographic Expert Group compression, a 
I ossy eomp ressi on ft in 1 1 at 

• JFIF JPEt i compression that does not conform to TIFF 
specifications. 

Compression and Decompression 

Image compression is a process of storing an image in a way 
that uses iess disk space than is used by (he uncompressed 
image. In developing I he compression and decompression 
routines for the HP linage Library; the image learn had to 
account for three factors: 

• The quality of the displayed image 

• The speed of decompressing and displaying the image 

• The amount ^compression required. 

The quality of the displayed image partly depends on whether 
lossless oj loss> compression is used Lossless compression 
involves techniques that allow the image to be perfectly re- 
istructed. This method of compression Stores the infor- 
mation about die repetitive patterns of pixels rather than 
storing every pixel For example, for a se< pienee < if 25 pixels 
each having a value of JI2, lossless compression Cdutd store 
two items; one pixel of value 92, and the information that, 
this pixel repeals 2"> tinu & 

Lossy compression is a method that uses different techniques 
to achieve even lower storage requirements than lossless 
compression, Uissy compression is recommended for photo- 
graphic images. For the HP Image Library, lossy compression 
is based on discrete cosine transform (OCT) techniques, 
These are numerical techniques that transform complex color 
or grayscale information into less complicated information 
Although (he origin.] I color or grayscale values are lost, the 
image norm; illy appears identical when it is decompressed 

and displayed 



Table ! 
File Types Supported by the HP Image Library 

File Type Reads Writes Typical File Contents Version 

TIFF Types 5.0, 6.0 

BitonaJ Yes Yes Line art, text 

aid white 
ph« 

Paiett e Yes Color photos ai 

screen dumps 

RGB Yes Yes Hi gh-quality color 

photos 

YChfr Yes y,-s High-quality color 

phot * >s 

Compressed TIFF Types 5.0, I M > 

PackBits Vis Yes Compression for the 

hitonal images 

LZW Yes Yes General-purpose 

compression 

C'CTIT Yes &s Common fax images 

<T[oup;i 

((ITT Yes Yes Common fax images 

Group 4 

JPEG Yes Yes High-quality color 

photos 

X Image Types X 1 1 

Xwd Yes No Pixmap image from 

Xwd (Z format) 

Xbm Yes No Bitonal X bitmap 

images 

Xpm Yes Yes Color ASCII 

X pixmap images 

JFIF Yes Yes Color photos an d 8-R8 

continuous tone 
images 

GIF Yes No Xv/Xglf network im- 87a 

ages, diahip services 

Starbase Yes No HP Starbase pixmap I 
Pixmap images 

t WriTing graysralK 1 fflteg a I only in fl-bit formal 

To address user concerns about disk space, the HP Image 
Library supports a full range of compression and decom- 
pression methods. Application programs can access t he- 
compression and decompression methods listed in Table 11 
through the HP Image Library. 

Except for JPH<r and JFIF compression, all compression 
method* are lussless. Although JPEf i is lossy, that loss is 
normally mvnoticenhle unless the image is compressed by 

n i < • n ■ 1 1 ian a fact or of 20 times. 

Typically, lossless compression methods reduce the storage 
requirements to 60% of the original disk space* However, by 
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Table II 

Compression and Decompression Methods Provided 
in the HP Image Library 



Compression and 
Decompression Method 

JPEG 

m& 

Group 3 

( "(ITT Group 3 

CCITTGroup4 

WW 

PackBits 



Image Types 

Grayscale, RGB, and YCbCr 

YCbCr 

Bitonal 

Bitonal 

Bitonal 

Bi tonal, grayscale, palette, 
RGB, and YCbCr 

Grayscale, palette, bitonal 



using the lossy JPEG compression technique, a typical com- 
pression reduces the storage needed to f>% of l he original disk 
space, However, the image library still displays the photo- 
graph with high-quality resolution and no noticeable change 
in display time. 

All the compression methods provide fast display and high- 
quality image appearance For JPEG, the fastest display im- 
plementation is provided in (lie version of the IIP Image 
Library supplied with HP M Power. With JPEG, the program- 
mer can choose the amount of compression by trading off 
I lie amount of compression with the image quality desired. 

Before compressing a color image file with JPEG, the appli- 
cation can save add it tonal space by First converting the file 
to YCbCr format and suhsarnpling it Siibsampling Is a tech- 
nique that reduces the color information to be compressed, 
without noticeable change in the image quality, Subsampling 
is really a form of compression, because it stores fewer pixels 
than exist in the image. Because the human eye perceives 
degrees of brightness with much higher resolution than ex- 
act shades of color, only a Traction of the chrominance sam- 
ples are stored- After subsampling> the subsampled bits can 
be replicated before displaying the image. The replication 
process is called upsamplmg. The upsampled image looks 
identical to the original image. 

If the application needs to send files to a fax machine, it can 
use the CCITT Group 3 and Group 4 compression methods. 
However, most fax machines support only Group 3 format. 
The HP Image Library can convert any type of image it sup- 
ports to any other type it supports. Therefore, a photographic 
image in RGB format can be converted to CCITT Group 3 
formal so thai the file can be sent to a fax machine, 

To compress images, end users must experiment with com- 
pression methods on various types of images. The following 
general guidelines are helpful in determining which compres- 
sion method to use for reducing the storage requirements of 
images: 

* For photographic images when some of the image detail 
can be sacrificed, choose JPEG (choosing the desired 
compression amount.) or JFIE 

• For Xwd (X window) screen dumps, or other computer- 
generated images, use LZW. 

♦ For image files being sent to a fax machine, use CCTTT 
Group 3. 



• For fax files to be stored or sent to HP MPower systems, 
use either CCITT Group 4 rif the content is mostly white 
space, such as text) or either Group 3 or CCITT Group 3 
iil the content is highly detailed ). 

• For images being ported to various non-HP-UX systems, 
choose PackBits. 

Display Quality 

Because the resolution of an image on paper can be 20 to 
100 times higher than that of the computer screen, end users 
are concerned about image display quality. To optimize the 
appearance of displayed images, the image team included 
the following capabilities in the HP Image Library: 

• Simultaneous display of different color images by sharing a 
common color palette for S-plane displays 

• Gamma adjustment of colors, such as changing Hie 
brightness of an image 

• Programmable choices for the type of dithering technique 
used 

1 Automatic dithering of images on S-plane displays and 

remapping of pixel tones 
1 Automatic conversion of color images to grayscale format 

on monochrome displays 
1 Programmable conversion of bitonal images to display as 

grayscale images. 

Dithering 

Dithering is a technique that trades screen resolution for 
more colors or gray levels. While the resulting image may be 
more grainy than the iindithered version, the contrast be- 
tween the greater range of colors or gray levels provides 
improved appearance. Dithering is accomplished by modu- 
lating the color values between two adjacent color tones, 
From a moderate distance. I he human eye automatically 
blends these regions of color together and perceives the 
average intensity, 

Two options are available in the HP Image Library for ditiier- 
ing: emir-diffusion dithering, using whal is called the Floyd- 
Steinberg method, and area-based dithering. Compared to 
eiTor-difhtsion dithering, area-based dithering provides a 
more matted appearance in the image (see Fig, 4a on page 
42). However, if speed is the primary concern an image can 
be displayed faster by using area-based dithering. 

For area-based dithering the HP Image Library- performs the 
following two steps; 

1. In one area at a timc h it applies an S-by-8 array of positive 
and negative values to the color or grayscale values, This 
step preserves the average color or grayscale level in the 
area, because the sum of the values in the array is always 
zero. 

In a simplified example, this step might subtract 20 from the 
value of half the pixels and add 20 to the value of the other 
half of the pLxels. Thus, the average value of the pixels in the 
area remains the same. 

2. The values from step 1 are reduced to a number of values 
that the screen can display. For example, in a grayscale image 
values 1 through 256 need to become values I through 32 for 
a monochrome screen. In this example, each value is divided 
by 8 (256/32), Pixels of gray level 1 through 8 become value 
1, values 9 through 16 become 2, and so on 
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In ernjr-cliffusion dithering, die HP Image Library changes the 
values of pixels one at a time rather than working on areas 
of pixels. After assigning a dithered value to one pixel error 
diffusion records what the difference was in that pixels 
value. That difference is then added to the next pixel's value 
before it receives its dithered value. 

For instance, suppose there are two neighboring pixels with 
values of 90 and 140. If the pixel with the value 90 receives a 
dithered value of 100, the differs * i is added to 

the next pixel s value of 140, making a pixel of value 1 50 be- 
fore j s its dithered value Perhaps I ilithered 
to 170, making the current difference . ? is added to 
next pixel and the process repeats. 

Error diffusion is the dithering method used by the HP 
MPower ImageView tool J whereas area-based dithering is 
the default dithering method. 

Before displaying an image, rite HP Image Library checks the 
characteristics of the display device to determine if dithering 
is necessary, The HP Image Library automatically dithers the 
image when displaying an RGB or YCbCr image on a pseudo 
color display device or displaying a grayscale image on a 
hi tonal device. 

For RGB images on a pseudo color device, the HP image 
Library' uses area-based dithering. For grayscale images on a 
hi tonal device, the library uses error diffusion. When a gray- 
scale image is displayed on a bitonal device, the IIP Image 
Library dithers it to ahitoual image. 

By default, the IIP Image Library chooses the dithering 

method by using the following criteria: 

If l he screen is a pseudo color (palette) image, area-based 

i lii tiering is used. The image is first converted to RGB and 

then to palette. 

If i he screen is monochrome (bitonal), error diffusion is 

used. The image is 1'irsl convened it) grayscale, then EO 

bitonal 

Image Conversion for Space and Readability 

For reasons such as saving space and (improving the reai I 
ability of text-oriented images, an application can convert 
images from one image type to any other image type. 

Space and Color Images. The high quality of a 2 1 hit R* SB im 
age is only visible on n . system When displayed on 

an 8-planc display system, an RGB image is automatically 
converted to paleihv However, an uncompressed --l-bii KGB 
image occupies more space lhan it would as a palette image. 

To save space on 8-plane display systems, the application can 
convert i he 21-bit RGB linages to palette or Y< b( r format 
YCbCr formal is preferable ifJPKG compression is also used. 
Beyond &e additional compression possible, the image 
space required can also be reduced through the siibsampling 

technique. 

Space and Text linages. O mcerning monochrome images, thi 
progrsuturter can save apace by converting grayscale images 
of text to bitonal images. A grayscale image requires eight 
times the space required by a bitonal image. 



1 ImagsVifiw is a tool for displaying, manipulating, saving, and priming amages of different 
image types 



HP Image Library Scaling Functions 

The HP Image Lilirary scaling capability performs three types of seating according 
lo wfcicft option is used: scale to gray, area-sample scaling, and simple scaltng In 
each case, the scaling algorithm accounts for the type of image involved, v. r 

~age type conversion is needed, and whether ifre program is requesting thai 
the image be scaled up or down. 

Simple Scaling 

Simple scaling gives the fastest scaling performance but the Id 

:e is enlarged and pixel decimation if 
The image is being reduced No image conversion is performed 

Area-Sample Scaling 

- i ample scaling gives trie highest-quality scaling results. This method only 
applies to scaling an Image down in the current release of the HP Image Library In 
scaling the image down, sample scaling uses area sampling techniques based on 
the image type; 

1 For a coior palette image, the image is first converted to an RGB image. The RGB 
image is scaled by area sampling. 

i For bitonal images, the image is temporarily converted to an averaged grayscale 
type and then the image's pixels are set to on or off. based on a threshold value 
set by the application. [High-Threshold values darken the image and low-threshold 
values lighten it.) The resulting grayscale image is then scaled by area sampling. 

Bitonal-to-Gray Scaling 

Bitonal-to-grav scaling applies only when scaling down bitonal images. It converts 
bitonal images to grayscale and uses area-sampling techniques to scale the image 
down. To convert a bitonal image to a grayscale image, the HP Image Library assigns 
each black or white prxel a gray level between and 255 



While a scanned photographic image should be a grayscale 
image to retain the different leveis of gray, a scanned text- 
oriented document or other lexl image can be bitonal and 
still be read from the screen by users. 

Readability and Text Images. When a grayscale image of text is 
stored ;is hiionai, it can he convened g ray scale if it 

was scaled down for display. The result is texl that is easier 
m n ;nl Thus, (lie image can be stored jis a bitonal image, 
using less spare, and displayed as a grayscale image. 

Image Manipulation 

To manipulate images, I he MP Image Library includes a num- 
ber of functions for scaling, rotating, mirroring, cropping, 
and c hangi n g i i n a g e co lore. 

Scaling Images, The scaling function maps one image into an 
image ofadifferem resolution. It allows the application fco 
account for the differences in resolution between the dis- 
play screen *u\i\ the image captured by devices such as scan- 
ners, li also provides a mechanism to resize images to differ- 
ent window resolutions (see "HP Image Library Scaling 
Fund ions, "above i. 

An application can scale an image up or down. For example, 
scanners are typically 300 dpi and display monitors are only 
90 dpi. Therefore, images scanned at 100 dpi or higher 
resolution musi be sealed down to the screen resolution, 

The scaling function includes t >\ >i b >ns for faster scaling or 
high-quality scaling. Faster scaling replicates or removes 
pixels, depending on whether (he image is being scaled up 
or down. High-quality scaling converts bitonal imagi 
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(a) \b\ 

Fig. 4. A comparison between (a) area-bused dithering and (b) error-diffusion <\\\\r.-n g. 



grayscale or scales color images by area sampling, Area 
Sampling replicates pixels based on the average color values 
of an area pi pixels, producing a clearer image- 
Rotating and Mirroring Images. The roiai ion function rotates 
an image at integer multiples of 90 degrees. The rotation can 
be clockwise or counterclockwise, if the image is rotated by 
90 or 270 degrees, the width and height of the image are 
reversed. Otherwise, the image retains the same dimensions 
as before rotation. The mirroring function mirrors the image 
about the x or y axis. 

Cropping Images. The cropping function extracts a rectangu- 
lar section of an image, creating a cropped image thai is 
either the same size or smaller than the original image. An 
application might combine the scale and crop functions to 
implement features such as panning and zooming. 

Changing Image Colors, The color mapping function changes 
the image colors by mapping the color values of the image 
pixels into d iff erent color values. This ft met ion can he used 
by applications to change the colors, brightness, or contrast 
of the image. 



Custom File Types and Custom Functions 

To allow programmers to extend the IIP Image Library, func- 
tions are included for defining new types of files and creating 
custom functions. 

Custom File Types, For unsupported types of image files, the 
programmer can extend the extensible file support library, 
The programmer de lines a new type of file using an extensi- 
ble file support function and Ihen rebuilds the extensible file 
support library. 

Thus, if an existing application accesses files through the 
extensible file support library, the newly defined file type 
am be accessed as just another extensible file support fi\e. 
Tl lis Object-oriented approach allows the programmer to 
creale routines wilhout worrying about what type of file is 
being manipulated. 

Custom linage Functions. For capabilities not available in the 
HP Image Library, the application can define a new function. 
An application-defined function (or custom function) can be 
a producer a filter, or a consumer function. 
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Fig. 5. An HP imageView screen. 

Application-defined produrera and consumers might be used 
in n m\ 01 write i«» ;in imag< capable device; The application- 
defined producer outputs a pipe image, ideally in strips, that 
may have an input image type that is an known to the image 
library hul known to the application-defined consumer The 
application-defined consumer can l» i defined to accept a 
standard or nonstandard input image type that is unknown 
to the HI' Image Library. 

An application-defined filter can be created to operate on a 
client image that is not in a format supported by ibe HP Im- 
age Library For example, the clieiil image can be created to 
support a color Image in ( MYK (cyan, magenta, yellow, and 
black) format. While standard IIP Image Libran functions 
can read and write ibis clienl image, operations to manipu- 
late the image require an application-defined [unction. 

End -User Image Tools 

Based on the image and extensible file support libr;i 
end-user tools have been created by the image team and 
several oi her IIP learns. For example, the HP online help 
Eacilrty, and the HP MPower components fax. DeskScan/UX, 
Whiteboard, Image View, and HP SharedPrint use Ihese 
libraries for image display and manipulation. 

A central part of the HP MPower image display is Image- 
View, au ( >SF/Motif-based image display application (see 
! A basic version of this app]k;iii'>n tsbuill inlo the 
standard run-time applications <>n IIP 9000 Series 700 and 
800 systems. 



As a client application of the image libraries. Image View- 
displays all the file types supported by the extensible file 
support library. The user displays an image by double- 
clicking on a file icon in HP Vl"K. The user can then zoom 
in on arbitrary' areas of specific interest and resize images 
by dragging a comer of the window. 

In the HP MPower version of Image View, users can also 
c ompress an i mage ft 1 e prim im ages , adj ust com rast . bright- 
ness, and orientation, and Also, users 

display images without dithering and fix the image scale 
.ring display. 

Image Developer's Kit 

The image (earn created an image developers kit that pro- 
grammers can use to create applications built on the HP 
Image Library, The applicatioas developed by programmers 
can be clients of the X server i * they can work solely with 
image files without using X Most applications access both 
image files and the X server because it is the only means for 
displaying images. 

The toolkit can be installed on HP 99000 Series 700 systems 
and consists of the following components: 

• Header files for the HP linage library functions 

• A range of Sample image files, such as TIFF, GIF. and Xpm 
files 

• Man pages that describe all HP bnage Library function calls 

• Source files for sample applications that contain calls to the 
HP Image Library functions 

• Makefiles that convert sample source files into executable 
programs 

• Source files thai show how (o extend the HP Image Library, 
adding support for other types of files 

• A utility called imageutil lhat provides command line options 
for image viewing and manipulation. 
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A Printing Solution for a Multimedia 
Environment 



For environments in which users are confronted with a myriad of printers 
to choose from, HP SharedPrint provides a simple graphical interface that 
enables users to select a target printer and a set of options without 
encountering the typical problems associated with this process. 

by John Mandler 



Most computer users in a networked computer environment 
take certain aspects of the system for granted — especially 
shared resources such as disks and printers. Users expert 
these resources to work flawlessly without any concern or 
interference on their part. Unfortunately, the ideal Ls not 
always possible, especially for printers. Printers often fall 
far short of users" expectations. Because of this, we placed 
special emphasis on providing a robusT, easy-to-use printing 
solution for f 1 P M Po we r. 

To understand the MP MPower printing solution it is II is! 
necessary to examine the fundamentals of a spooled print- 
ing system. Fig. 1 shows the phases and basic operations of 
a spooled printing system. 

The user controls the specification phase by selecting an 
output device from a list provided by the system. The object 
(Tile) to print forms a second part of die the job specifica- 
tion. Finally; any options that control the appearance of the 
final output should be noted. The options may be used to 
control when the job is printed, to define die desired feed- 
back, to select some feature of the output device, or to 
specify the final appearance of Ihe printed output 

The queue and control phase is handled by the native spool- 
ing system. It packages t he users job specification, locates 
the large! machine, establishes the communication path, 
and places the job in a queue. The spooling system eventu- 
ally dequeues the job, invoking the functions that process 
the job, and directs the output to the printer. The spooling 
system also handles query and control requests from the 
user; providing the feedback required for a robust system. 



The processing phase performs the real work in a printing 
subsystem. This phase is initiated by the spooler, which 
starts a process that connects a dequeued file to the process 
input and the printer data port to its output port. The pro- 
cessing phase performs the translation mid formatting of the 
input data stream, applying options as appropriate, and 
sending out printer control functions to the selected printer 
when necessary. 

Problems 

Each of these three steps — specification, queue/control, and 
processing — has problems that can range from nuisance 
issues such as the printer is out of paper to a compete break- 
down of the printing subsystem (see Fig. 2). Problems in the 
specification phase include the need for the user submitting 
a print job to spend time finding the names and capabilities 
of available printers and spending more time learning how 
to add special printer control options to a print request. The 
options give the user more control over the final look of the 
document. 

Queue and control problems include minimal to no feedback 
on the stale of a job or printer. Failures are often not re- 
ported to the user, giving the appearance that jobs just dis- 
appeared from the queue. Administering the spooling system 
can be a difficult I ask, The steps to add a printer are not 
obvious and modifying a printer's default behavior requires 
more knowledge about the printer and programming than 
the user mav want to know. 
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Output to Printer 



Fig. 1. Basic Gph-ratiui. ot a 
spooled printing system. 
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Pig, 2, Problems associated with 
some spooled prmttng systems. 



The problems encountered during the processing phase can 
be the most difficult to diagnose and fix. Consider that the 
print job process is a background process running on a 
server, which is often remote from the user If the wrong 
operations are performed on a print job t the result can be a 
hung spooling system, no output, or pages of useless output 
from the printer Determining the Failure requires intimate 
knowledge of the spooling system and any shell scripts or 
programs the spool system executes. 

HP SharedPrint Solutions 

The HP Mpower printing subsystem is based on the HP 
SharedPrint product it solves many of the printing problems 
mentioned above by providing a robust, easy-to-use sitbsys- 
tern layered on top of a spooling system. The HP Shared- 
Print solution addresses the specification phase by provid- 
ing a graphical user interface tool that includes a list of 
punters to choose from and a highlighted list of options that 
can be specified for a particular printer (see Fig. 3), 



HP SharedPrint provides tools that enable the system admin- 
istrator to set up a printer easily and quickly, making customi- 
zation trivial. Another graphical user interface tool provides 
real-time status of print jobs and printers, along with control 
functions to cancel print jobs, add or delete printers, and 
modify a printer's default behavior (see Pig. 4 (. Both of 
these tools are described in detail later in this article. 

The HP SharedPrint processing modules eliminate the major 
problems that cause system administrators and end users so 
much trouble. An intelligent server provides print job pro- 
cessing based on an algorithm that dynamically builds and 
executes the elements necessary to handle the job properly. 
Built-in error detection logic is used to provide a hard-copy 
message to the user detailing any problems in processing 
the job. 

HP SharedPrint Overview 

HP Shan (IIYint has a client-server architecture. The client 
components include the two graphical user interface screens 




Fig. 3. KP Shared Print graphical 
i ium.Ha list of 

available prmtera. 
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Fig. 4. HP ShunxIPrmfs graphical user irttetface for systoa 
adminLstialitjn. 

mentioned above. Fig. 5 shows a high-level view of the HP 
SharedPrint client/server system. The job specification cli- 
ent communicates with I he HP SharedPrint sender via Hie 
base spooling system. The server provides real-time- feed- 
back to the user about what options are valid for a specific 
job and printer combination. 

One of the major features of HP Shared hint is its ability to 
print many of the common file types! transparently on any 
of the supported printers. This functionality eliminates the 
need for the user to know which file types can be printed on 
which devices. 

The HP SharedPrint server, being highly configurable, can 
be used to drive smart as well as dumb printers. Also, be- 
cause of its highly modular design, the server can be layered 
on any spooling system. 

Fig, 6 shows a detailed view of the main components that 
make up I he HP SharedPrint client/server system. The HP 
SharedPrint. client contains the graphical user interface pro- 
grams sprint (HP SharedPrint. print) and spadmin (IIP Shared- 
Print administration). Sprint prompts die user for the file to 
print (J in Pig. 6) awl I he designated printer and then uses 
NCS (network computing services) to connect to the HP 

t A file type is a special data format required of alt printers, such as PCL image files, RTL (fa-sEer 
transfer language], PostScript, or applications (image or text) 



SharedPrint feedback server @ and ®> The feedback server 
hands sprint a set of valid options based on the users inputs 
i . Tire option information is used to validate which options 
the user can select for the current job. 

After completing the job specification, the user selects the 
OK button in the sprint window to queue the job for printing. 
At this point the job request moves to the line printer spooler 
(Ip) client ' . The lp rlienl packages the print request and 
connects to the Ipsched daemon located on the Ip server®. 
The Ipsched daemon places the job request in the printer 
queue and at the appropriate time starts the IIP SharedPrint 
job processor to process the job jf)« 

The HP SharedPrint server includes the HP SharedPrint job 
processor, configuration files that specify various mappings, 
filters, and drivers that perform translation and formatting, 
and the HP Shared Print feedback server. Data from the con- 
figuration files is used by the feedback server and the job 
processor. The feedback server uses the data to provide 
option information to the sprint user interface, and the job 
processor uses the data lo define the processing steps. The 
job processor invokes the filters antl drivers to finish process- 
ing a job. The filters translate and format data fdes going to 
the selected printer, and the drivers place device-specific 
control information in the data stream going to the printer. 

The Print Client 

The sprint print client enhances the basic HP VUE printing 

model by providing an easy-to-use graphical interface. Sprint 

does not alter or replace the current HP-UX* spooling system 

functionality but is layered on top of the spooling system. 

This leads to a smooth transition from the standard HP-UX 

printing models to HP SharedPrint. The sprint graphical user 

interface allows users to: 

Select a file lo print via a drag and drop operation from the 

HP VUE file manager interface 

Select a printer from a displayed list of printers 

Set options based on real-time feedback 

Save groups of options for reuse later on similar print jobs. 
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The top level interface for sprint is shown in Fig. 3. The 
dimmed buttons represent unavailable items. For example, 
the menu item PaperSource is dimmed to indicate that I he 
selected printer does not support multiple paper trays* 

The button marked Options will take the user to the screen 
shown in Fig. 7. This screen provides another set of options. 
These options are sent to sprint by the feedback server. 




The Administration Client 

The HP SharedPrint administration (spadmin) graphical user 
interface is shown in Fig. 4, Selecting the printer icon from 
the HP VUE front panel activates (he spadmin client. [Vint re- 
quest or printer status informal ion is displayed and updated 
every 30 seconds. The Administer menu enables more com- 
plex tasks such as editing printer configuration files, adding 
and deleting printers, and making other changes to the print 
spooler state. 

Core Server 

The IIP SharedPrint core server components are shown in 
Fig. 8. The core server performs ihe processing for a print 
job and provides the options feedback to the user Two 
groups of configunilion files are used for processing a job. 
One group contains information thaf defines job professing 
and feedback rules, The other group contains printer config- 
uration information that defines the default settings and 
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behavior for a particular printer There 1 is one printer config- 
uration file for each printer connected to the system. Filters 
and drivers are standalone programs invoked by the core 
server to process a print job. 

The core server consists of two separate processes that 
share a common set of data ami some common functions. 
These processes are I he job processor and the feedback 
server. The job processor is invoked by the print daemon 
Ipsched with the arguments: 

jobjd user_name title copies options files 

The first four arguments represent die job number, the user 
who queued t lie job, the title of the job, and the number of 
copies to print. The options argument contains zero or more 
tokens , each representing an option specified by the user 
queuehig the job. For example -c h a rti eight 8 -orientation landscape 
are typical tokens in the options argument. These options arc 
set in the sprint client or on the Ip command line by prepending 
i tie letter -o to the option string. The files argument is a list of 
one or more files to lie printed. 

The job processor serves all the supported printers by 
dynamically configuring itself for each print job, The infor- 
mation needed fortius operation comes from the printer 
configuration file. Each printer requires a unique printer 
configuration file, which is created when a printer is added 
to the system. This configuration file can be modified at any 
tune via the IIP SharedPrint client spa dm in or by using any 
text editor. 

The job processor uses some control programs to read the 
configuration files to determine which set of filters to execute 
to print a job properly. Details of these steps are described 
later. 

The other process in the core server, the feedback server, is 
run on every system where an HP SharedPrint printer is 
installed. This server provides the sprint interface with feed- 
back on what options are valid for a specific file and printer 
combination. 

The feedback server is automatically started when the first 
HP SharedPrint printer is added to the system. Other HP 
SharedPrint printers on the same system use the same HP 
SharedPrint server 

Configuration Files. The configuration files shown in Fig. 8 
are text files that provide all the information necessary to 
process any of the supported file types on any of the sup- 
ported printers. Users can modify any of these files using 
an editor, or in the case of the printer configuration file, the 
HP SharedPrint system administration utility spadmin. The 
Configuration tiles include: 

* Printer model files. These files contain information for spe- 
cific printer models. For any particular printer model, this 
file includes the options supported, default values for any 
filters, and the file types the printer model can handle. 

• Printer configuration file. This file contains information 
about a specific printer. The file is created from one of the 
printer model files when a printer is added to ihe system- 
Users can modify this file to reflect changes made to the 
printer, such as sw 7 applng paper trays or inserting font 
cartridges. Changes take effect at the next print job. 



• Object name extension file. This file contains a list of entries 
that map file extension values to file types. For example, files 
with the extension c (C source files) would be mapped to 
an ASCII file type. 

• Pipeline file. This configuration file specifies a filter pipeline 
process for each combination of input and output file type. 
Each of the filter specifications can include options and 
white space. 

• Options map file. This file lists supported options for each 
filter or driver. 

• Options file, This file lists known options and aliases. 

• "Types file. This file lists known file types and aliases. 

These last five configuration files make up the files labeled 
as job processing and feedback rules in Fig. 8. 

Filters. Alters are programs that transform a data file from 
one format to another. Filters perform either translation or 
formatting. Translators change ihe encoding of the informa- 
tion in the data Hie without changing its appearance. For 
example, in converting ASCII text to PostScript format the 
text, remains the same, but the file is expanded to contain 
PostScript commands. Formatters modify how the informa- 
tion in the data file will be rendered on the page. For exam- 
ple, a formatter might rotate or scale an image, add com- 
mands for mult i column text printing, or add footers and 
headers to a document. These filters often have options that 
the user can set to control the final appearance. 

Filters are invoked by the job processor. Each filter reads 
from standard input and writes to standard output with error 
messages being sent to standard error The filters supported 
by HP SharedPrint include: 

• tx pel. This filter formats and translates text documents into 
PCL (printer control language) format. The formatting op- 
tions allow 7 users to change point size T print portrait or land- 
scape, perform double column printing, add headers and 
footers, and change the typeface and symbol-set mapping, 

• taps. This filter formats and translates text, to PostScript II 
also supports most of the options included in the texMo-PCL 
filler txpcL 

• cgmhpc]l2,This filter reads binary CGM (computer graphics 
metafile) formal and produces an HP-GL 2 byte stream. It is 
used to obtain 2D graphics output from Star Base or 
HP-PHIGS CGM files. 

• psrip. This filter allows users to print a PostScript file on a 
non-PostScript printer. The filter reads a level- 1 PostScript 
file and creates a raster image for each page, The raster 
image Ls fed to a device-specific formatter which adds the 
appropriate control or command codes for the target 
device, 

• pdrip. This filler performs the same function as the psrip filter 
on POL files. The PCL level can he level 1 through 4 and can 
include the level-o PCL scalable typefaces, ]\ L3h . used hy 
the HP PaintJet, PaintJet XL and DeskJet 500C printers, is 
not supported by this translator. The IIP-GL 2 extension to 
level-5 PCL is also not supported by this translator. 

• i l-R I ter. This is an image library filler that converts all HP 
MPower supported image formats, a level- 1 PostScript file, or 
a PCL 4 file into a Postscript, RTL t or PCL file. The filter is 
composed of three stages: a producer that converts the input 
object into an image Library format, one or more filters that 
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manipulate the raster Image, and a consumer that converts 
the image library output lo a PostScript, PCL or RTL file. 

Drivers. The fimerion of a timer is to add job control infor- 
mation to the data stream produced by the filters. It does 
not interpret or change the data stream, but adds printer- 
specific commands to the byte stream. Think of the driver as 
handling printer-specific funr-i i> Iters handle 

language-.spmJic fund i 

The job control information depends on the target printer 
Each job control feature in the printer can be selected or set 
by ! I administrator when the printer is configured 

i it specified by users in their personal options files. 

In most cases the driver will send a header with any job con- 
trol information then cat the input stream from the filters to 
the output stream. In some cases, the driver will have to 
examine the first few bytes of a file to see if there are any 
resel confro) characters that might interfere with the driver 
header si ream, For instance. PCL files may contain an ESC E 
thai resets the printer state. The driver w ill have to si rip 
these bytes if a header must be m 

Processing Steps 

For each print job. the IIP SharedPrint job processor exe- 
cutes the algorithm outlined in Fig. 9. Each of the steps 
in Fi£. y represents a module or inline code involved in 
processing a job. 

Parse Command Line. This step is the interface to the base 
spooling system. Each spooling system passes the job data 
to the processing modules in a well-defined form. For the 
HP-UX spooling system, the job processing module is called 
via the tpsched daemon with the six command line arguments 
described earlier. The command line information, whirl i 
includes the user name, printer name, joh options, and files 
lo print is collected and stored in the job processor for use 
as appropriate. 

The ma in purpose of tliis module is to enclose fiie Specifics 
of a spooling system in one location SO thai f he process of 
polling HP SharedPrint to a new spooling system would 
involve changing only this module. 

Get Printer Type. A key step in properly processing a joh is to 
know the characteristics Of the larget device. One such 
printer characteristic is the type of languages or file types 
the printer understands. 

The printer file types are listed in the printer configuration 
file, which is created when a printer is added to the spooling 
system This shp involves parsing I he configuration file tor 
the target printer. If nti file- type entry exists in the configura- 
tion file, or the configuration Rlv cannot be located, an error 
page is sent to the printer, the printer is disabled, and a mail 
message is sent to the user who queued the job. 

Build Options List. Each job includes a list of options and as- 
sociated values. The options list is built from default values 
defined in the printer configuration file, values passed by 
tit*- user, or values added by the filters. User-specified op- 
rinns override options defined In the printer nmfiguration 
file or the fill ers. 

User-Specified options can be passed from sprint via I he lp 
command line. Since the HP SharedPrinl option names are 
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Fig. 10. f'u^Scrifil baiUWff page. 

full-length si rings, a set of aliases, which are defined in the 
options configuration file, can be used on the Ip command 
line. The build-opt ions-list operation will expand the aliased 
strings when the options list is built 

Front Banner Page. This step involves building and sending a 
I turner page to the printer. This function creates a banner 
page file, (hen recursively calls the job processor to send il 
to the printer. In this way, any type of banner page can be 
sent to any printer. HP SharedPrint includes a banner page 
program for PostScript, PCL 5, and ASCII text. Rg. 10 is an 
example of the PostScript banner page. 

Get File Type. This step determines the spooled file's file type. 
The jot) processor must know the file type of a job to deter- 
mine if any processing is necessary to format the spooled 
file for the target printer. For instance, a PostScript file must 
be converted to PCL to print on an HP LaserJet printer. The 
file-typing process uses the following three methods (in the 
order given) to determine the file type for a job: 

* Command line switch 

• File type reader 

* File extension value. 

When a file type is found from any of these methods, the 
file- typing process terminates. If the file type cannot be de- 
lennined from any of the above methods, an error page is 
printed, and the job is aborted. 

• Command line switch. With this ineihod if the user includes 
the file-type option flag (-filejype ) on the command line, the 
file-type value will be set to the value following the -fjle_type 
flag. In this case HP SharedPrint assumes the user has some 
knowledge of the file's content that HP SharedPrint cannot 
determine. The sprint program will also prompt the user for 




Selecti 




Fig. 1 1. The spnm dialog box asking about 6fe ■> 

the file type if the job processor cannot determine the file 
type. In this case sprint will pop up the dialog box shown in 
Fig, 1 1 T asking the user to select one of the values. 

File type reader. This method compares the spooled file's 
contents with a predefined set of patterns for specific file 
types. These patterns are coded as C programs or Korn shell 
scripts. Each one of these programs or scripts expects a file 
as input. If the file type mat dies the defined pattern, the 
program or script writes the type siring to standard output, 
and returns an evil code nf to the calling routine. II there 
is no match, the program or script returns an exit code of 1. 

A special file- type program, based on the image library, is 
used for identifying hunge files. The image library includes a 
set of functions that allow programmers to open a file and 
determine if it is a file type that is supported by the image 
library. If the image library can pr< feesa the file, the image 
file -type program whites the string "bitmap" to standard 
a i it | mi and exits with a status code of 0. 

The module thai det en nines a jobs Hie type executes each of 
the file-reading programs and scripts located in a directory 

called filetypes until a match is found. If no match is found 
after all the programs have been invoked, the file extension 
mechanism is used to determine the file type. 

File extension value. File extensions are used by HP VUE to 
map file types to actions. For example, the extension au is 
associated with the audio server, a process that plays or 
records audio files. HP SharedPrint uses many of the same 
extension values, mapping them to a file type in the object 
name extension file. The extension value is extracted from 
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Fig, 12, Pipeline stages created 
during ine building step 

in the job processing phase 



the leaf name of the original file that is passed by sprint in 
the Ip spooler title option. 

Build Pipeline. The processing pipeline performs the actual 
work of getting a tile printed on the target device, The pipe- 
line consists of one or more filters and a driver, with the 
output of each stage piped into the input of the next stage as 
shown in Fig. 12. 

The pipeline is derived from the printer Hie type and the 
data file type. The pipeline builder scans the pipeline config- 
ii nit toil file looking for file type matches. For each match, 
one or more filters is specified to perform the translation. If 
no match is found for the specified file types, an error page 
is printed and the job is aborted. 

The pipeline is terminated by adding a driver module to the 
filter pipeline. The driver is determined from the printer 
qcfafiguraiion file. The pipeline string at this point will have 
Hie format: filter 1 1 filter^ I driver. Note that each filter might 
be a filter name followed by some options that control how 
the filter is executed. 

The pipeline is completed by adding the appropriate options 
lo each filter and the driver The filter options file maps op- 
lions thai apply to each filter or driver so that the correct 
arguments are passed lo (he filters. The final pipeline string 
might look Like: 

txpcl -charheight 8 orientation landscape f Ij3sh -copses 1 

Execute Pipeline. The pipeline created in the build-pipeline 
stage is now executed. The output from the last stage of the 
pipeline is sent lo standard output, which will be the I/O 
connection to the pi inter 

If any errors occur in the pipeline execution phase, they are 
Collected and placed on an error page, which is printed at. 
the end of the job. The error page function is called when 
some uti recoverable event occurs. A special log file contains 
all the output from the print script. Each filter or driver 



writes all error or warning messages to standard error The 
job processor redirects this text to the error log. 

At the completion of the job, the job processor scans the 
error log. If any information or messages are found in the 
error Jog, the job processor builds a text page containing the 
errof messages and some debug information and then prints 
the text page on the printer. 

Diagnostic information is included in the error page to aid in 
the analysis of the problem. 

Final Steps. The last-copy step executes the pipeline again if 
another copy is needed, and the last-file step cycles the script 
hack through processing the next file if there are multiple 
Hies to print. When recycling is required, the initial stale of 
the options , printer configuration file, and uutpul type re- 
main the same and do not need to be recalculated. Finally, 
the rear banner step, which is identical to the front banner 
page, may be used to print just a short trailer, or in the case 
of printers that print face up, the banner page should be 
printed here. 

Feedback Server 

The feedback server helps users specify job parameters that 
optimize the hard-copy output for a given job. Without this 
feedback, users can be easily overwhelmed by the large 
number of available options. By enabling only those options 
that apply to the current job, the feedback server guides the 
user through the job specification process. 

The feedback process shown in Fig. 13 begins with the user 
Sheeting a file to print, on a specific printer. The sprint pro- 
gram uses I he network computing services (NCS) to connect, 
to the server and ask for a list of valid options. The feedback 
server executes the algorithm shown in Fig. 13 and returns a 
list of valid options to the client The sprint program then 
enables the user to select only the options returned by the 
feedback server, disallowing (by dimming selections on the 
menu) other options to the user. 
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HP SharedPrint Options 

Tht 1 options that apply to a given print job are a function of 
not only the target printer, but also any filters that may pro- 
cess the job. In the simplest situation, a file whose type 
matches the printer type can be sent without any filtering. In 
this case the set of valid options will be a function of the 
physical features of the printer, such as duplex or paper tray 
selection. 

Even in the case in which the file type matches the printer, 
filters can be inserted to perform some preprocessing or 
formatting. For example, a PostScript document can be 
passed through a filter thai places more than oiu- logical 
page on a physical page, 

HP SharedPrint precomputes the fillers that will be used to 
process a job. This information is then used to extract the 
supported options from one of the files containing the job 
processing and feedback rules. It is this set < if options tlmt 
the user sees in the graphical user interface 

Along with each option is the value attached to that option. 
The filter processing the job must be fed both an option and 
a value. The source of the value comes from one of three 
locations: the user, the printer configuration file, or the filter, 
in descending order. For example, if the user specifies an 
option and value, this pair is passed to the lllter. Otherwise 
if a value exists in the configuration file, it is used. Finally, if 
an opt ion and value are not passed to a filter, the filter uses 



a built-in default value for the option. In this way, the behav- 
ior of a filter is controlled first by the user T then the system 
administrator (via the configuration file), and finally the 
programmer. 

One problem with options is that there is no unified naming 
scheme. Two filters may provide the same functionality and 
use different strings to denote an option. HP SharedPrint 
addresses this hy providing the options file to alias filter 
Option names to a set of names defined by HP SharedPrint. 

Conclusion 

HP SharedPrint provides HP MPower with a robust printing 
solution. Users can drag rind drop any HP MPower object to 
any printer and use the HP ShamlPrinl graphical user inter- 
lace to control the printing process, 'Hie graph ical user in- 
terface decreases user frustration, providing an easy-to-use 
printing interface. The intelligent server lowers the system 
administration burden by eliminating catastrophic failures 
and providing the flexibility to customize a printer's behavior, 

PostScript fs a trademark of Adobe Systems Incorporated which may be regjslered in certain 
jurisdictions, 

HP-UX is based nn and is compatible with UNIX System Laboratories' UU\X* operating system 
li also complies with X/Open's' XPG3, POSIX 10D3.1 and SVID2 interface specifications. 

UNIX is a registered trademark of UNJX System Laboratories inc. in me U.S.A. and otfiet countries. 

X/Qpen is a trademark of X/Open Company Limited in the UK and other counines, 
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Faxing Documents in HP MPower 

The ability to transmit documents via standard telephone lines is greatly 
enhanced with the HP MPower fax utility which provides automatic 
dialing, transmission, and delivery of fax documents from a workstation, 

by Francis P. Sung and Mark A. Johnson 



Over the past Ten years a revolution has occurred in tde- 
rummumcations that has resulted in rhe capability to trans- 
niit documents easily and inexpensively using standard 
telephone communicatUm channels. The fax machine has 
become pervasive on a global scale and is now a required 
tool for collaboration by all types of businesses. This suc- 
cess can be attributed to the standardization of fax commu- 
nication and the introduction of low-cost t easy-to-use fax 
machines, 

HP MPower fax provides a new level of refinement and 
capability hi fax communication. HP MPower fax provides 
the following advantages and features: 

• Client/server technology allows each HP MPower fax user 
access to fax capabilities at each user's desktop while shar- 
ing a fax modem at a remote location. Tins results in low r er 

i < ist per user compared to multiple fax machines and more 
convenient access compared to sharing a single lax machine. 

• Online documents can be conveniently faxed by dragging and 
dropping the document on the fax icon in the IIP MPower 
user interface This eliminates the process of printing and 
scanning the document into a fax machine. Document qual- 
ity Improves significantly since quality degradation occurs 
during the printing and scanning proci 

• The problem of waiting for access to a fax machine is elimi- 
nated. Faxes sent from MP MPower fax are queued before 
being I ransuutted. If 1 II* MPower fax is busy sending or n i - 
ceiving another lax. ihe fax waits in the queue and is auto- 
matically sen! at a later time. Also, if the destination fax 
machine is busy HP MPower lax will automatically retry the 
lax transmission al a lalertime. 

• Paper use is eliminated Received faxes can he archived and 
viewed without printing, Online documents can be faxed 
directly without printing. 

• Reliability is greatly improved since lax modems are 
inherently more reliable than fax machines. 

• Costs are reduced by providing the capability to queue out* 
going faxes for transmission when telecommunication rates 
are lower. Also, faxes that are being sent to the same number 
can be automatically batched together, saving die lypically 
higher rale associated with the first minute of transmission, 

• A palette t if custom fax cover sheets can be conveniently 
created and accessed. Each custom cover sheet can include 
i 11 stum images such as corporate logos as well as fax 
sender information such ;ls name, company, department, or 
any other information the user requires, 

• A detailed log of all fax transmissions mid receptions is 
kept This can be tided io monitor telecommunication 
charges and generate acoouni billing Information. 



» Security of fax access is greatly enhanced. Different classes 
of HP MPower fax users can be created with varying privi- 
lege and security levels. Some classes could have the ability 
io send faxes to international fax numbers at any time of 
the day, while other classes might be restricted to local fax 
numbers and transmission times when telecommunication 
rates are discounted. 

» Perhaps the biggest problem with a shared fax machine is 
the inability 7 to route incoming faxes directly to the intended 
recipient. Incoming faxes can be viewed by anyone standing 
near the fax mac bine and are easily nusp laced or lost , To 
avoid this problem, IIP MPower fax can route incoming 
faxes directly to the recipient using a bar code on the cover 
sheet or the origination number of the fax. 

HP MPower Fax Configuration 

HP MPower fax uses a clienty server configuration. Common 
functionality used by all HP MPow r er fax users resides on 
the fax server. Interaction with each fax user occurs at the 
fax client. Multiple fax clients are connected to a single fax 
server via a TCP/IP network connection. A fax client may 
also coexist on the same machine as a fax server. Up to 10 
fax modems can be connected to a single fax server Each 
fax modem supports a connection to one phone line. Fig, I 
shows a typical configuration in which IIP MPower fax 
operates. 

Major features at a fax client include an OSF/Motif graphical 
user interface, archival of received faxes, and a user-created 
directory services database of possible fax recipients, Major 
features offered by the fax server include fax modem com- 
munication, rendering, queuing and scheduling of outgoing 
faxes, temporary storage and routing of received faxes, and 
i >x t ens i\ e t latabases for controlling sen- er configuration, 
customization, and automation. 

The process for transmitting a fax begins with the user 
selecting the filet to be faxed from the graphical user inter- 
face at the fax client. The file is then transferred to the fax 
server where it is combined with a cover sheet and rendered 
into the correct TIFF Class F formal. The fax server then 
schedules the fax for transmission and stores if in a queue. 
When the appropriate time comes for transmission! commu- 
nication with the fax modem begins and ( lie fax is moved 
from the server queue to the fax modem and over the 
telephone line. 



T Multiple files can also be sent id The fax server m ihe same time, 
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Standalone Fax Machine 




When a Tax is received, the fax server at the receiving end 
Initiates communication with the fax modem and stores the 
incoming fax in temporary storage. If the fax can be routed, 
it. is transferred to the appropriate fax client and the user is 
notified Otherwise, the fax is stored in a general-delivery 
location on the fax server and all fax users are notified. 

The process of transmitting a fax from a client and receiving 
a fax at a server is described in more detail in the following 
sections. 

Fax Client 

The primary component of the fax client is an GSPYMotif 
graphical user interface that allows sophisticated fax users 
to use the advanced functionality of the fax server while 
also enabling occasional users to send and receive faxes 
easily. The fax client's graphical user interface is integrated 
with HP VUE and other IIP MPower components so that 
tasks such as ttragging and dropping files to he faxed T print- 
ing received faxes, and scanning documents for inclusion in 
faxes are easily accomplished. 

The user initiates a fax transmission by selecting the fax 
icon located on the IIP VUE front panel or the HP MPower 
media panel. This causes the Compose Outgoing Fax window to 
appear (see Fig. 2). This is the primary window for creating, 
viewing, and sending faxes. An HP MPower fax user can 
send a fax by simply entering the fax number, dragging and 
dropping the fax attachments (Tiles to be sent), and then 
selecting the Send Fax button ASCII PCL, PostScript,™ and 
EFSt files are automatically detected so the user does not 
need to know the file types or the attachments. The user can 
then select the Fax Status .. button to monitor progress of the 
fax as it is being transmitted. The complete fax with cover 
sheet and attachments can be viewed before sending by 
selecting the View Fax., button. Since the cover sheets and 
rendering! t capability reside on the fax sewer, the fax client 

t EFS h or extensible fife support, is a pert of rhe HP knege Library thS and the HP Image I ibrary 
are described in the article on page 37. 

ft Rendering is any form of drawing operation, including text, line, and raster output. 



Class 2 Fax Modem 

Fi#. 1, A i,\ j mc; 1 1 in-ru 'irk i ur [fig- 
uration in which HP MPower 1;lx 
up* 'rates* 

transfers the attachments to the fax server for rendering 
and then moves the rendered fax back to the fax client for 
viewing. 

Advanced features in the Compose Outgoing Fax window are 
configurable so that sophisticated users can easily use ad- 
vanced features without compromising ease of use for occa- 
sional fax users. The default configuration for the compose 
screen is a simple interface in which the user can gradually 
expose and use advanced features as they are learned. 

Advanced features include a directory service database, email 
confirmation of transmitted faxes, handwritten signature 
placement on a fax cover sheet, automatic fax transmission 
at a specified later time (to lower teleconununicarjon costs), 
automatic printing of transmitted faxes, bar code genera- 
tion, and selection of optional styles and classes. The style 
of a Tax determines the cover sheet appearance and physical 
size of the fax, Class determines the priority and parameters 



Fax — Compass Outgoing Fax 




Composition Options Task Admin 


Kelp 


To 






I -i'f:i AJlaa: 


Lookup Ml* 


I 






Clear Alias 




Altf-Bxtt 

NunA 
Message: 


1 SGS.436 5121 
















JJbIJd tooift* 


J 


Attachment. 


E 

Fflolttnta 




AiUchiKani Am.. | 






J 

J 

1 


1 ': : .— 'i 


AdrtOttiBt... | 




Fntet Filfl Name: j 


Add File 














VlwwFsx^ Send Fax Fax5tntui, r < 


Clotfl 




All field* BXC-efrt Fa* # if* optional. 





Fig. 2. The HP MPower fax window fur composing fax messages. 
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Setoct gorwraJ ctoti v to check other received Faxes that may be your*. 



Fig. 3. The HP MPov, 



for scheduling and transmitting the fax. A directory service 
database can he r reared and manipulated on the client that 
contains the fax number, an alias name, and other pertinent 
information about frequent fax recipients. After creating an 
alias entry, the user only has to enter the alias of a fax recip- 
ient, which will cause the fax number and other pertinent 
data to be automatically accessed from the database and 
placed on Hie fax cover sheet Multiple fax recipients can he 
gn mped together into a group alias and saved in I he direct 
tory service database. The user can enter l he group alias 
name to send a single fax to multiple destinations al once. 

In addition to file data T two other types of fax attachments 
can be generated from the Compose Outgoing Fax screen, A doc- 
ument scanned in from a scanner attached to the client's 
machine can bo attached as pari of an outgoing fax. Also, ;i 
snapshot of any currently displayed window can be captured 
and included as part of a fax. 

Received faxes are manipulated from the Browse Received Fax 
screen | Vi-A 3), Paxes that have been received can be anno- 
tated, printed, replied to, and archived in user-created fold- 
ers. Typically, a lax is received by the nix server and placed 
in ;i general-delivery area All fax users are I hen notified hy a 
change in the appearance of the fax icon symbol located on 

I he HP VUE front panel When the user selects I his icon, the 
Browse Received Fax screen will appear instead or the Compose 
Outgoing Fax screen. The cover sheet of any lax in general 
delivery can he viewed from this screen. After viewing the 

cover si i. a user can claim a fax I hat appears to he lhal 

user's own. < 'burning a fax moves the lax from general deliv- 
ery on i he lax server to an Inbox on the fax clierd when 1 the 
entire fax can he viewed from the Browse Received Fax screen. 
For ins tall at ions in which confidentiality is very important, 
access lo general delivery can he limited to a single individual 
user or group* This privileged user or group can view die 
cover sheet of each fax in general delivery and route IttO 
li,. appropriate in-hox. 

Received faxes that have a bar-code symhol on the cover 
sheet can he routed directly lo the in-hox of the recipients. 
The fax Server has a bar-code symhol decoder lhal scans all 
incoming fax cover sheets Tor a bar code, If a users bar-code 
symhol is detected, i he fax is routed directly to I hat users 
in-box without going through general delivery A bar-code 
symbol can he generated on the cover sheet of a fax trans 
milled hy HP M Power fax Tor reception and routing hy Other 
UP M Power tax servers- For reception and muling of nixes 
originating from fax machines, a return cover sheet with I he 
ns.r s bar-code symbol Can he generated. This return cover 



sheet is transmitted as the last sheet of a fax destined for 
the fax machine. The user at the fax machine can then use 
this return cover sheet as a fax cover sheet when replying. 
This allows faxes originating from fax machines to be 
routed when received hy the IIP MPower fax server. IIP 
MPower fax can be set up to route all faxes that originate 
from a specified fax number to go to a specified fax user. 
This is useful if all faxes originating from a Certain fas 
number are always destined to the same user. 

Fax Server 

The function of the fax server is to allow access to the fax 
resource from multiple fax clients simultaneously, while 
enforcing proper access control, accepting requests For nix 
transmission and scheduling, and receiv mg and disposing of 
incoming fax transmissions appropriately. To provide these 
services, the fax server is implemented as several programs 
thai are run as separate processes. These processes main- 
tain a set of datahases and control some private directories 
and files. This complexity provides many of the advanced 
features offered by the fax server. A default configuration is 
provided with the product that allows any Tax client to send 
and retrieve fax transmissions immediately after installa- 
tion. With the default configuration, IIP MPower fax is as 
easy to use as a standalone fax machine. 

Fax Server Architecture 

The HP MPower fax server is divided into three major func- 
tional components: the client-connection component, the 
fax-transmission component, and I he fax-reception compo- 
nent. Eleven databases control the behavior of these three 
components. Fig, 4 shows the major components and 
databases of the fax server. 

The circles to Fig. 4 represent programs, some of which are 
nm as individual processes while others are Invoked hy the 
running processes as required, The parallel lines represent 
databases or storage areas. 

The fax server components interact with the information in 
the databases lo handle transmission and reception of faxes 
and communication with clients. The next lew sections will 

disi us.s ih,- databases show ti mi Fig 1, and Following lhal. 
the major functional components of the fax server will he 
described* 

Fax Databases 

The eleven fax server databases provide flexibility configur- 
ability, expandability, convenience, and advanced features 
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such as least-cost scheduling and incoming fax routing. 
These databases can be grouped into three major groups; 
user databases, scheduling databases, and routing databases. 

User Databases. The databases used by the fax server to 
maintain access control information about HP M Power fax 
users include a permission database and a user database 
(see Fig. 5). 

Permission database. The permission database maintains a 
list of permission groups into which users can be placed. 
Capabilities such as access to general delivery and the abil- 
ity to become a fax administrator can be given to specific 
permission groups. Permissions to connect to the fax 
server, to use specific accounts, classes, dialing rules, print- 
ers, and styles, and to register for a bar code or a caller- 
identifier are ail grained on a group basis. (Bar codes and 
caller identifiers are used for routing incoming faxes. ) 
User database. To connect successfully from a fax client to 
t he fax server, the user must be listed hi (lie user database 
and belong to a permission group thai has permission to 
connect to the fax server. The user database also controls 
the range of network addresses from which a user can initi- 
ate a connection request. With each user entry, a network 
mask and a network address are kept. When a user invokes 
the fax client, a connection request to the fax server is initi- 
ated. If the result of AN Ding the network address of the users 
workstation with the network mask listed in the database 
entry for that user matches the net work address in that entry, 
the connection is accepted. Otherwise, the connection is 
rejected. 
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Scheduling Databases, The following databases are used by 
the fax server when scheduling outgoing faxes: 
Account database. Each outgoing fax submitted by any fax 
client is required to specify 7 an account to which the call will 
be charged. Each outgoing fax is logged in the account log 
together with the duration of the call and die account to be 
charged. The account database maintains the list of accounts 
available to users. 

Class database. One of the advanced features of the fax 
server is the ability to schedule an outgoing fax for trans- 
niission when the cost of the call will be least expensive. 
This feature is railed teast-cosi scheduling, which is con- 
trolled by the specification of the class of service defined 
for the outgoing fax. The class of service also controls 
which phone lines, if there are more than one in the system, 
are allowed to be used for transmission. If a fax transmis- 
sion should fail because of a busy signal or no answer at I he 
receiving end, retry attempts will be made later. The class of 
service also controls the time between retries as well as the 
maximum number of retries permissible. The class database 
maintains the various features provided for each class of 
service. 

Style database. The style specified with each outgoing fax 
nmtrois the resolution used for I he transmission, the paper 



length, and the appearance of the fax cover sheet. Such 
information is maintained in the style database. 
Fax-line database. The fax-line database tells the fax sc 
how many fax modems have been configured for use by the 
fax server. It also contains information necessary for initial- 
izing the fax modems. If the system has more than one fax 
line, not all of them behave identically. For example* some 
fax lines might be connected to regular telephone tines and 
some to leased lines Because < if the different transmission 
lines, the fax-line database contains entries called trunk 
groups, which join together fax lines that have identical 
behavior. When an outgoing fax is eligible for trans mission, 
the fax scheduler will pick the unused and least expensive 
fax line from among the trunk groups allowed by the partic- 
ular class of service. Pig, 6 shows the entries in a typical 
fax-line database. 

Tari IT database. Local telephone companies and long dis- 
tance earners charge different rales depending on the time 
the call is made and whether the call is local or long dis- 
tance (see Fig. 7). The tariff database is used for maintain- 
ing such information about these rates. This information is 
required for the least-cost scheduling feature described 
above for the class database. 
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i Dialing-rule database. Another advanced feature of the fax 
server is the ability to convert any given Tax number into the 
appropriate string of numbers to be dialed. Wir h a properly 
set up dialing-rule database, the fax server can determine if 
it can ignore the area code in a lOdigit fax number if the 
number represents a local call. The server can also deter- 
mine if a fax number needs extra numbers to add a long 
distance access code. With pattern matching capability, I he 
olialing-rule database has the flexibility to fulfill die dial string 
conversion needs of very different systems such as internal 
telnet systems that require outside line access codes, or sys- 
tems I hat have different access codes For various long dis- 
tance carriers. Another function of the dialing-rule database 
is to associate each converted dial string with a particular 



trunk group and tariff entry. Through this association, the 
fax scheduler can determine the least-costly way to send 
a fax. Fig. 8 shows the entries in a typical dialing-rule 
database. 

Printer database, The printer database maintains the list of 
printers available to 1 he Tax server and the. associated com- 
mands required to print, the acknowledgment of an outgoing 
fax. When a fax is submitted, the user can select to print an 
acknowledgment of the fax. 

The fax scheduling databases are siunmarized in Fig. 9. 

Routing Databases. The routing databases are used by the fax 
server to control how incoming faxes are handled for each 
user. 
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* Action database. The action database maintains actions to 
be performed on incoming faxes on a per-user basis. Each 
user can specify a number of action entries, all of which are 
private to the user. Each action entry- may include any or all 
of the following types of actions: 

Queue the fax to the in-box of a particular user 

Send email to an email address 

Forward the received fax to a fax number 

Execute some shell command. 
The most eommonly used action is queueing the received 
fax to the in- box of the user who owns the action entry. 

• Dispatch database. The dispatch database is presented to 
the user as bar-code registration and caller-identifier regis- 
tration. Bar codes are typically associated with faxes sem 
from workstations and caller identifiers are typi rally the 
telephone numbers associated with standalone fax ma- 
chines. By registering a bar code or a caller identifier the 
user defines an action entry to he performed by the fax 
server when an incoming fax has a bar code on the cover 
sheet or a caller identifier from a fax machine that is similar 
to what is being registered. The user may choose to allow 
other users to register for the same bar code or caller identi- 
fier if it lias not been registered and disallowed by another 
user. Typically, bar codes are not shared, while caller 
identifiers may be shared. 

Default Configuration. In the default configuration, the user 
database is empty. The fax server will accept any connec- 
tion requests from any fax clients originating from anywhere 
on the network. Any user can submit outgoing fax requests 
using any of the accounts, classes, and styles present at the 
fax server. The default dialing-rule database has one enti> 
thai will match any fax number and dial il as is. The default 
action and dispatch databases are also empty. Thus, all in- 
coming faxes will be left in the general-delivery area Any 
list 1 ? is allowed to access the general-delivery area to check 
for received faxes In this default configuration, the behavior 
of Mil' fax server is very much like that of a slandalone fax 
machine. 

Fax Server Components 

The fax server components shown in Fig* 4 contain the pro- 
cesses that interact with the fax databases to handle com- 
mt miration with fax clients, the transmission of faxes, and 
the reception and distribution of incoming faxes, 

Client-Connection Component. The client -eonneci ion compo- 
nent is the process that rommtuiiratcs directly with fax 
clients. It accepts or rejects connection requests from fax 
clients according lo information stored in the user and per- 
mission databases. Once the connection has been estab- 
lished. The user at tfoe Eas « Nent can submit outgoing fax 
requests as- well as look at received faxes plared in the 
client's in-box folder With the right permission, the user can 
also check and claim received faxes stored in the general- 
delivery folder, if the user is a fax administrator, a received 
fax can be routed from the general-delivery folder to die 
in-box folder of another user 

When an outgoing fax request is submitted to the elient- 
connection component, the permission database is accessed 
to see if the user is authorized i«> use the account, class, and 
style specified in the request The dialing-rule database is 
accessed tu see if the fax number matches any of the dialing 



rules the user is allowed to use. From the style specified* the 
cover sheet is located For the request. After these checks the 
appropriate fax renderers are invoked to render the cover 
sheet and attachments (if any) into TIFF Class F images. 
These images and a command file are kept in the fax spool- 
ing area tnider the directory /usr/spool'ta^destinatjons. The trans- 
mission component described below will scan this area and 
schedule the fax for transmission. Fax renderers provided 
with HP MPower support ASCII PCL and PostScript files. 
and all EPS file types supported by the HP Image Library, 
including TIFF. GIF, JF1F. JPEG, Xpnu Xwd, and Xbm im- 
ages. The HP Image Library is described in the article on 
page 

In addition to subnutting and retrieving faxes, other admin- 
istrative operations such as access or modification to any 
entries of the databases are also executed over the connec- 
tion between the fax client and the client-connection com- 
ponent. The user needs to be a fax administrator to request 
such operations. 

The estabiislunent of a connection between the fax client and 
the client-connection component is mediated hy the internet 
daemon inetd. Appropriate entries are made in the files /etc/ 
services and /etc/inetd.conf when HP MPower is installed to lei 
inetd know how the connection can be established* If the 
NISt (network information service) is used, the NIS master 
versions of these two files must be modified to include these 
entries. 

Transmission Component The transmission component con- 
sists of the processes that are responsible for schedi il I r iu 
outgoing faxes and transmitting the rendered images to the 
fax modem. The fax scheduler process is responsible for 
scheduling, while the fax renderer ami Tax transmitter 
processes are responsible for rendering and transmitting. 

The fax scheduler is rim as a background process. Only one 
SUCh process should run on the system on which the Tax 
server is running. It wakes up every minute and scans the fax 
Spt m »ling area where all the submitted and rendered faxes are 
kept. The command file of each outgoing fax contains 1 1 l* * 
class of service information (defined in the class databas 
that the fax scheduler uses to determine whether a particular 
fax is eligible for immediate transmission or not If the fax is 
eligible For immediate transmission, the fax scheduler checks 
to see if any of the fax lines that the user is authorized lo use 
are free. If a free line is found, the fax transmitter is invoked 
to stall the fax transmission OH thai line. 

If the fax transmission fails because rhr di -m mat ion fax num- 
ber is hus.v mi dors not. answer, die fax will not be eligible 
for retransmission mil il the Susy Retryjnterval or No_Answer_ 
Retry_ Interval specified hy the class of service for Ihe trans- 
mitted fax elapses, if the fax transmission fails because of 
transmission error, the fax will not be eligible for retrans- 
mission until the Tx Failed _Retry J nterval elapses. Fax transmis- 
sions that fail after the successful transmission of a number 
of pages will continue from the failed page when retrying 
transmission. If the fax transmission failure reaches die re- 
spective retry limit specified by Hie class of service, the fax 
will be put in the suspended queue. The user then has the 
npi km to send il again to the same fax number or to try a 
different fax number. 

' Thfi network information serpen provides '.iiuhal ^ministration of large network systems 
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Both successful and failed fax transjuissions are Logged Ui 
the account log together with the duration of the calls and 
the accounts used. This helps to rectify fax phone charges to 
specific cost centers. When accessing the account log, regu- 
lar users will see only the fax transmissions they submitted, 
while fax administrators will see all the entries. 

Other operation status information is also logged by the fax 
scheduler and fax transmitter in the system log for diagnostic 
purposes. Only fax administrators can access the system log. 

Reception Component. The reception component consists of 
the processes responsible for monitoring incoming fax calls, 
receiving incoming fax images, and dispatching the received 
faxes. These tasks are accomplished by the fax listener, the 
fax receiver, and the fax dispatcher processes respectively. 

The fax listener is run as a background process. Each fax 
line on the system is monitored by an individual fax listener. 
If an incoming call is detected, the fax: receiver is invoked to 
receive the fax images on that line. The fax receiver and the 
fax transmitter are located in the same program. 

When reception of an incoming fax is finished, the fax dis- 
patcher is invoked to determine how to dispose of 1 he newly 
received fax. The fax dispatcher provides one of the ad- 
vanced features of the fax server called maoming fax rout- 
ing in which an incoming fax will be automatically routed to 
its recipient if there is routing information available with the 
fax. This feature is described in detail later. If no routing 
information is available, the received fax is placed in the 
general-delivery folder. Users with general-delivery access 
permissions are able to view the first page of received faxes 
in the general-delivery folder and claim them or route them 
to the correct recipients. This mimics the behavior of a 
standalone fax machine. 

Incoming faxes are logged in the account log. Only fax ad- 
ministrators can see the entries for incoming faxes in the 
account log. 

HP MPower Fax Advanced Features 

The advanced fea tmes currently provided in HP MPower 
fax include the ability to pull together several pieces of 
information to determine the most, cost-effective way to 
schedule and transmit outgoing faxes and provide automatic 
routing of incoming faxes. 

Least-Cost Scheduling. When an outgoing fax is submitted, 
the fax server cheeks the class specified for the fax to deter- 
mine which trunk groups can be used for transmission. Next, 
the fax number is checked against entiles in the dialing-rule 
database that the user has permission to use. The dialing- 
rule entry that matches most of the digits in I he fax number 
( not counting those matched with patterns) is used if it can 
be used in at least one of the trunk groups found above. For 
each trunk group specified in the dialing-rule entry, the asso- 
ciated tariff is noted and used for determining the least ex- 
pensive way to transmit the Tax. The fax server then makes 
a table of time periods within which the fax is allowed to be 
transmitled. together with the costs associated with each 
time period This information is stored in the command file 
for that lax. 



When the fax scheduler checks the command file of each 
outgoing fax to see it the fax is eligible for immediate trans- 
mission, it first checks to see if the user selected the Waitja_ 
Send option. If this option is used and the specified time baa 
not arrived yet, the fax is not eligible for immediate trans- 
mission. One reason for choosing the Wait_to„Send option 
might he to avoid transmitting when the the receiving fax 
machine is busy. A fax can be delayed for up to 24 hours. 

If the specified time arrives for the Waitjo_Send option or 
thai option was not chosen in the first place, then the dead- 
line for transmitting thai fax is checked. The deadline for 
transmission is specified in the class for the fax. It is mea- 
sured from the time specified in the Wait_to_Send option, or 
from Hie time when the fax is submitted if die Waft_to_Send 
option is not chosen. If the deadline for transmission passes, 
the fax scheduler will schedule the fax for immediate trans- 
mission, ignoring cost. If the transmission deadline has not 
passed, the fax scheduler will consult the table of time peri- 
ods in the command file to see if the current time fails in the 
least-expensive time period before the deadline for trans- 
mission arrives. If the current time is in the least-expensive 
range, the fax is eligible for immediate transmission. 

Incoming Fax Routing, When an incoming fax lias been re- 
ceived, the first page, usually the cover sheet, of the received 
fax is scanned by the fax dispatcher for a bar code. If one is 
found, the dispatch database is checked to see if such a bar 
code has been registered by one or more users. If found, the 
actions associated with each bar-code registration will be 
performed. Next, the dispatch database is checked to see if 
the caller identifier of the received fax is registered to one or 
more users. If found, the actions associated with each caller- 
identifier registration will be performed Such actions may 
include any combination of rouling the received fax to the 
in-box folder of the user, sending email notification to the 
user, forwarding the received fax to a different fax number, or 
executing a user-specified shell script. Forwarding a received 
fax to a different fax number is very useful if the fax recipient 
is temporarily at a different site that can receive fax. 

With incoming fax routing, faxes that are directed to a par- 
ticular user, say by a bar code, can be placed in the users 
in-box folder inunediately without the delays usually in- 
volved when it is placed in the general-delivery area waiting 
for someone to dispatch it manually. Avoiding the general- 
delivery area also provides better confidentiality 

Other Interfaces to HP MPower Fax Server 

Apan from sending and receiving taxes via the fax client, 
two other interfaces are available for submitting outgoing 
faxes. One of them is the fax email daemon, and the other is 
the simulated printer interface. Note that these interfaces 
provide only a small subset of the functionality and features 
of the fax client 

Fax Email Daemon. The fax email daemon is run as a back- 
ground process on the machine on which the fax server is 
running. Users who are on a system that cannot execute the 
fax client can send email to faxemd@<fax_server>, where 
<fax_serwr> is the machine on which the fax server, and thus 
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the fax email daemon, is running. By providing the fax- 
specific header information m ihe beginning of the email 
the body of the email will be sent as a fax by the fax entail 
daemon. The following keyword-argument pairs are required 
in the fax-specific header 



Keyword 


Argument 


From: 


Sent ier name, sender title 


Style: 


Style name 


Class; 


class name 


Account: 


Account name 


To: 


Recipient name, recipient title 




Fax number 



Only the ASCII contents of the body of the email can be 
sent Bile attachments are not supported. 

Si inulated Printer Interface 

The simulated printer interface, faxlp, allows users to submit 
outgoing faxes as though Ihey are queueing to a printer. The 
command to use is: 



Ip-dfaxlp-ofrom: Jane Doe* -a'elass: Standard' -o... the_file 

where theJHe is the file thai will be sent as a fax. Here, 
thejile may be an ASCII file or a PCL file. This interface al- 
lows the addition of fax capability to applications that sup- 
port a printer interface withouT having to make modifica- 
tions to the applications to accommodate a fax machine. 

Conclusion 

The client/server architecture of the HP MPower fax prod- 
uct provides an easy-to-use but Full-featured fax capability 
to HP 9000 computers. Its advanced feature* of least 
scheduling can save on telephone costs. By minimizing the 
need for human attention, productivity of everyone is in- 
creased. Finally, HP MPower fax enables users to use their 
fax resources more cost -effectively. 

OSF/Motif is a trademark of the Open Software Foundation in the US and other rot** 

PostScript is a trademark of Atfobe Systems Incorporated which may be registered in certain 
rJons 
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Audio Support in HP MPower 

Multimedia capability promises to enhance the communication and 
presentation of information through the use of real-world data types such 
as audio and video. Compact-disk-quallty audio Is the first of such data 
types to be offered as a standard feature on all of HP's new workstations. 

by Ellen N. Brandt, Thomas G. Fincher, and Monish S. Shah 



HP MPower provides the hardware and software to allow 
recording and playing of audio files over a network, incorpo- 
rating audio in email, adding audio annotations l.o system 
files, and recording and playing to external devices like tape 
recorders, CD players, and VCRs, With these capabilities 
audio-enabled applications can add voice annotation to doc- 
uments ranging from spreadsheet rows and columns to CAD 
drawings. Programmers might add audio comments to their 
programs. Error messages could take the form of spoken 
messages, or even distinctive sounds that convey more in- 
formation than a simple beep. Finally, background music 
could be added to presentations. 

This article describes HP MPower s audio functionality, 
application development tools, and audio hardware and 
software architecture. 

Audio Tools 

The audio tools provided in HP MPower allow users to re- 
cord, edit, and play audio data in a variety of file and data 



formats. HP MPower also provides tools for converting be- 
tween audio formats. All of these tools are built on the audio 
library, which defines the application program interface to 
HP MPower's client/server audio implementation. The appli- 
cation program interface, libraries, widgets, and header files 
are available to Ihird-party software developers who wish to 
use audio in their applications. 

The Audio Editor. The audio editor is based on OSF/Motif 
widgets and audio library (afib) functions. The audio editor 
enables the user to record, play, and edit audio files in a 
variety of file and data formats. II displays a waveform rep- 
resentation of the data to make editing easy and supports 
basic editing tasks like selecting, cutting, and p as ting. The 
main screen for the audio editor is shown m Fig. la. 

The audio editor can he invoked or redisplayed by clicking 
on the audio icon on the HP MPower media bar. Dropping a 
file from the HP VUE file manager onto the audio icon will 
bring up the audio editor with the file already loaded and 
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displayed, A file can be loaded into an already visible audio 
editor by dropping the file icon onto the editor screen. 

Audio Control Panel. The audio control panel is an OSF/Motif 
interface to global audio parameters such as volume and 
output device selection (see Fig. lb \. Ml cooperating audio 
applications can use the control panel so the user afwa 
knows where to go to control these attributes. The audio 
urol panel also provides a Stop button that will stop the 
current play operation from any cooperating application, 

The audio control panel allows 1 he usef to turn monitoring 
on or oft, Monitoring involves listening to the audio input 
signal. In a conventional tape recorder monitoring allows 
the user to listen to the audio signal being recorded On a 
workstation that has HP JVlPower. mom luring can be used 
whether or not anything is being recorded. For example, a 
user can monitor the workstation s line inputs from a CD 
player or VCR even when recording is not in progress 
without using the CPU or other system resources. 

Audio Playback, An audio file can be played by simply 
double-clicking on the files icon in the file manager or in an 
audio-enriched mail message. The file will begin playing 
according to the set lings of the audio control panel A file 
can also be played by dragging its iron from lite file manager 
to the speaker icon on the HP VIJE front panel 

Other Functionality. In addition to the graphical interfaces to 
audio fund ionatfty mentioned above, there are some other 
capabilities shipped wilh HP M Power lhai are accessible 
from a command line. In the directory /usr/audio/bin execut- 
ables for the audio editor (audm.editor ■'), the audio control 
panel (AudroCP), the double-click function (send_sound_), and 
the convert and attributes programs are provided. The con- 
vert program converts audio files from any supported file 
format, data format, and rate and number of channels to any 
other format and rate. The attributes program tells every- 
thing that, it can determine or guess about any audio file 
including file format, data format., sampling rate, number ol 
channels, data length, and header length. 

Audio Data and File Types 

A number of audio data and file types exist in the industry 

today, making it difficult for audio files to be shared in a 

heterogeneous environment ■. 

The lack of standards for audio is currently being addressed 
by groups such as the IMA (Interactive Multimedia Associa- 
tion). This organization and others are trying to develop 
standards so that someday there will be a clearer picture as 
to how in store audio information in a formal that is accessi- 
ble to everyone and can be easily incorporated with other 
aspects of multimedia. 

In the meantime, we chose to support two of the existing 
file formats and to develop conversion utilities that allow us 
to support sampling rales, dat;» ionit;ils. and byte ordering 
methods that are nol supported directly by our audio 
hardware. 

File Format. A file format is a structure in which there is infor- 
mation about the data as well as the data itself. This infor- 
mation may reside exclusively in a header at the beginning 
Of the lileor may be interspersed in Vhunks" throughout the 



file. In the latter case, it is possible that only terrain types of 
chunks are pertinent to audio. 

Pertinent information for audio files includes the sampling 
rate, data format, number of channels, compression tech- 
nique, and number of samples. Sometimes there is additional 
information such as loop points or edit markers. 

The two audio file formats we chose to support include 
Microsoft - RIFFAVaveform. which is chunk-based, and the 
NeXT/8un audio format, which is a file header followed by 
data. 

We also support audio files that contain only the raw sam- 
ples. Although this is a popular method of storing audio data 
and it can be useful in a heterogeneous environment; we 
recommend using a file format with a header whenever pos- 
sible because the attributes oft he audio data cannot tie 
determined from the samples themselves. 

Data Format. Data format defines the method in which audio 
samples are stored. The most basic method is linear PCM 
(pulse code modulation). The signed amplitude of the audio 
waveform is quantized at fixed intervals of time. Each step 
of the quantization has equal size. This format is very easy to 
work with and is preferred by most audio editing and mixing 
routines. One of the formats that our audio hardware sup- 
ports is the 16-bit linear PCM T which is used by compact 
disks and is popular on UNIX*-systenvbased workstations. 

An unsigned version of 8-bit linear PCM is very popular 
among Macintosh and PC users because instead of having 
an amplitude range of -128 to +127, unsigned (or offset) 
8-bit linear has an amplitude range of to 255, All samples 
are offset by 128. For example, silence, which is normally 
quantized as 0, is recorded as 128. 

We also support the CCI1T (International Consultative 
Committee for Telephone and Telegraph) u-law and A-law 
standards. These are companded PCM formats. In these 
formats the straightforward linear scale is replaced with a 
base-eight logarithmic scale such that, there are small sl< !p 
sizes at low signal levels and large step sizes at high signal 
levels. The result is a better signaJ-to-noise ratio and the 
abihty to represent the dynamic range of 13-bit or 14-bit 
samples with only 8 bits, u-law and A-law both specify 8-bit 
samples at 8000 samples per second, u-law is very common 
on UNIX-system-based workstations. An overview of the 
A-law and u-law data formats is provided on page 65. 

Sample Rate. The sample rate refers to the number of digital 
Samples used to represent one second of analog audio. The 
greater the number of samples, the more accurately the 
audio signal win be reproduced A sample rate of 8 kHz 
(8000 samplers) can reproduce human voice wilh adequate 
clarity, hul it does a very poor job on music. For music, 44.1 
kHz (44, 100 saiuples/s) works well, The music on all com- 
pact disks is recorded at this sample rate. 1 ligital audio 
tapes (DAT) have a 48-kllz sample rale, producing slightly 
better audio quality. The audio hardware ( described later) 
supports all of these sample rates plus a few others. 

The sampling rate is also subject to the Nyquist criterion, 
which dictates that the sampling rate must be at least twice 
the rate of the highest frequency being recorded. Higher 
frequencies will typically be filtered out by the recording 
hardware. 
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may be local or remote. The server side provides a consis- 
tent interface to the client side, handles control of the audio 
device, and performs data I/O. 

The audio server (a server) interfaces multiple clients to the 
audio hard ware , allowing simultaneous play and record, 
queuing of multiple play and record transactions, priority 
preemption, and dynamic buffering. 

The audio server also supphes information to the client side 
about the attributes of the connected audio hardware. The 
audio library provides the capability to convert various audio 
attributes to ones that are supported by the connected hard- 
ware. Therefore, the hardware attributes (sampling rates, 
data formats, byte ordering, etc.) do not need to be the same 
on the client and the server. 




Earphones Microphone 
Fig. 2. (.:]k:iit/servtT architecture for the audio software. 

Multiple Channels. Although audio files with more than two 
channels do exist, most are either mono (one channel) or 
stereo (two channels). Hie two channels in a stereo file are 
typically interleaved on a sample by sample basis. This 
means there will be a sample for the left channel, followed 
by one for the right, followed by the next one lor the left" and 
so on. 

Byte Ordering. One problem with supporting files across a 
heterogeneous environment is That I he byte ordering of the 
local hardware may be different. In our audio structure we 
supply information about the byte ordering of the audio 
hardware connected to the system. Unfortunately, there is 
no easy way to determine the byte ordering of the audio data 
in a file that is imported from elsewhere. Therefore we are 
forced to make assumptions. We assume all RIFF/Waveform 
files use least-sigiuflcant-byte-first order and that all other 
files use mostsignificant-b>te-first order. Tins applies even 
to the files created by our audio tools. 

Client/Server Architecture 

The audio system softw r are uses a client/server architecture 
that is modeled after the X Window System (see Fig. 2). The 
client side provides a consistent interface to application 
programs and handles the connection to the server, which 



Support for Application Developers 

Since our audio software subsystem is closely modeled after 
the X Window System and OSF/Motif, we provide a library, a 
server, widgets, and a toolkit that are very similar to tiieir X 
counterparts. When appropriate, we followed the X conven- 
tions in our implementation of the various components. For 
example, the naming convention, function argument conven- 
tion, and event and error handling of the audio library all 
follow the conventions used in Xlib. An application devel- 
oper who is familiar with X and OSF/Motif should find it 
easy to incorporate audio functionality. 

The audio server handles ihe interface to the audio driver 
and provides control of audio transactions. This isolates the 
audio client from hardware-specific device calls and allows 
a higher level of transaction control than would otherwise 
be possible. 

The audio library is conceptually much like the X library, or 
Xlilx The audio library provides Ihe low-level application 
program interface for audio. The audio library provides 
functions that allow an application to connect to one or more 
audio servers, to manipulate the configuration of the audio 
hardw r are controlled by the servers, to control recording 
from a server to a file or data stream, and to control play- 
back from a hie or data stream to a server. The audio library 
also provides the capability Tor applications to play audio 
from any of several popular Die and data formats and to 
save audio in any or those formats. 

The audio widgets provide high-level access to record and 
play functionality. The application developer can use the 
widgets without having to learn the lower-level audio library 
calls. The audio widgets don't export all the functionality of 
the audio library, but. they do provide some flexibility 
through the use of resources that can be specified by the 
client application. 

The audio toolkit provides callbacks for audio events. Since 
it is not desirable for audio events to interfere with other 
events w r hen an application is using the X toolkit, the audio 
toolkit allows the X Toolkit to detect audio events and call 
the audio toolkit event handler. 

Several example programs are also provided for developers. 
These include the source code and Makefiles. Some of the 
examples use the widgets and toolkit, and others use only 
the low-level audio library calls. 

[continued on page 66 f 
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Overview of A-Iaw and ^i-law Data Formats 

An analog audio signal is continuous m time and amplitude (Fig 1&J, m cent- a 
digital audio signal is discrete in time and amplitude An analog-to-digital con- 

d to convert an analog audio signal to digital formal This conversion 
consists of two separate steps sampling and quantization Sampling converts the 
analog signal Iron discrete time by capturing the 

analog signal at regular intervals in lima TtieorettcalJy. tne sampled signal only 
has a value at those sampling times fig I b stows the sampled version of the 
signal in Fig la. 

The process of quantization maps each sample value to a number These numbers 
are represented with a fixed number of bits, giving them limited precision. The 
Quantitation process picks the number that best approximates the amplitude of the 

sample. Essentially, each step in the digital code represents a quantum of increase 
lor decrease) in the amplitude Hence the name, quantization Fig. 1c shows the 
signal after quantization, along with the digital codes assigned to each quantiza- 
tion level A digital audio stream is simply a sequence of such digital codes Al- 
though Fig, 1c shows only a few quantization levels, actual implementations use 
thousands of levels. 

The most straightforward form of quantization uses fixed-size quanta of ampli- 
tude. In other words, each step in the digital code represents the same step size in 
amplitude. In this scheme, the mapping from amplitude to digital codes can be 
represented with a linear function Iknown as linear quantization) Fig, 2a shows a 
linear mapping function 

A-law and u-law define a kmd of mapping in which the digital code is roughly 
equal to the logarithm of the amplitude. Although both laws use the same basic 
idea, the actual mapping equations are somewhat different m the two laws .Also, 
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Fig. 1. The srages t>l converting an audio anatog signal from analog to digital formal 
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Fig. Z Methods of quantisation (a) Linear mapping, or linear quantization, fb) Logarithmic 
mapping function and its piecewise linear apprn.*.'rniitmn 

to simplify the conversion to or from linear quantization, a piecewise linear 
approximation is used. Fig 2b shows a logarithmic mapping function and its 
piecewise linear approximation 

Telephone companies use A-law and u-law iq carry long distance conversations 
because these formats save bandwidth. For telephone conversations, signal 
strength may vary as much as 30 dB because some callers have softer voices than 
others, or some microphones are more sensitive than others It is necessary to 
maintain a 35-rJB signal- to- noise ratio (SNR) over the entire range. With linear 
mapping, quantization noise remains independent of the amplitude level, so one 
must design fnr G5-dB signal-to-noise ratio |30 dB + 35 dB} to meet the require- 
ments As the signal strength vanes over the 30-rJB dynamic range, the SNR vanes 
between 35 dB and 65 dB. This solution delivers a higher SNR than required at 
most amplitudes to meet the SNR requirement at minimum amplitude The price 
for exceeding the SNR specification rn a linear mapping scheme is that 12 bits per 
sample would be required. However, using A- law or ji-law, 35-dB signahto-nnise 
ratio can he maintained over a 30-dB amplitude range with just eight bits This 
works because logarithmic mapping has the property that larger signal amplitudes 
result in larger quantization steps. Thus, quantization noise is proportional to the 
amplitude, maintaining a reasonable SNR across a broad dynamic range. This is a 
more efficient way to use the quantization levels, making eight bits per sample 
adequate Thus, the use of A- law or u-law results m a 33% reduction m telephone 
audio transmission. The same benefits are realized in computer audio. 

The differences between A-law and u-law are minimal The U.S.A., Canada, and 
Japan use u -law for telephone transmission, whereas most other countries use 
A-law for telephone transmission While A-faw is somewhat easier to implement, 
u-law provides slightly better quality at low amplitudes. Note that A-law and 
u-law work well with voice audio only Tor high-fidelity music reproduction, linear 
mapping with IB bits per sample is typically used. 
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Audio Hardware 

While audio components such as microphones and speakers 

wurk wiili analog signals, the workstation CPU rnanipulairs 

data in digital form. Thus, to record audio on u workst;i , 

the analog audio signal must be convened to digital lorm 
using an analog-to-digital converter. Similarly, audio p lay- 
back requires a digital-to-analog converter. The add ii ion of 
these components turns a workstation into a versatile tape 
recorder — one that can provide rapid access to a large num- 
ber of audio clips and associate them with other data types 
within the workstation. 

By supporting several options for sample rates and data for- 
mats and offering a choice of stereo or monophonic sound, 
the audio hardware used on IIP 9000 workstations allows 
tlu 1 user to make the appropriate trade-offs between quahry 
and storage requirements. For example, higher sample rates 
n 'si ill in better quality, but also require more storage. The 
user has the freedom to choose the appropriate quality. 

The audio inputs and outputs are compatible with most con- 
sumer equipment, which allows easy connectivity. Two types 
of inputs are offered on our audio hardware: microphone 
and Line in >: lor V< Rs and compact disks). ( )nly one or these 
may be selected at any given time. Three outputs are avail- 
able: speaker, headphones, and line out. Any com hi nation of 
outputs may be activated simultaneously, but they will all 
output the same signal. Although the audio design supports 
these five types of inputs and outputs, some workstations do 
inii contain all five connectors because of space restrictions. 
Input and output may be activated simultaneously, which 
means that simultaneous recording and playback is allowed. 

Audio under the UNIX Operating System 

Audio presents a special challenge to a UNIX system because 
audio is an isochronous data type. Isochronous means con- 
stant with respect to time. This implies that the system must 
process audio samples at exactly the specified sample rate. 
If it slows down or speeds up, the listener will perceive dis- 
tortion in the audio. Unfortunately, the UNIX operating sys- 
tem was not designed to w T ork with isochronous data types. 
In fact, the I 'NIX system supports multitasking, which 
means that the CPU splits its effort between any number of 
tasks that nught be active. Obviously, when there are more 
tasks outstanding, each task gets less time from the proces- 
sor. This makes it impossible to guarantee that the audio 
hard wart 1 will get as much processor lime as it needs. 

Even the hardware infrastructure of the workstation can 
interfere with audio operation. Just as the CPU cannot guar- 
antee adequate attention lo audio, the system bus cannot 
guarantee adequate bandwidth for audio. The audio hard- 
ware design team's challenge was clear; overcome these 
difficulties while maintaining low cost. 

The Solution 

The problem description above makes it dear thai a solution 
thai guarantees isochronous operation under all conditions 
does not exist. The designers instead chose an approach 
that achieves isochronous operation under most conditions. 
That approach calls for putting a reasonable, not worst -case, 
upper bound on the delay for any given operation and com- 
puting how much audio data could be consumed or produced 




Fig. 3. Block diagram uft.hr audio I/O hardware within a simplified 
rrprcscnutour' - ■! -i i -.Mi: n i :';l workstation, 

in that time, A FIFO buffer of that size is required to cover 
that delay. For example, a heavily loaded CPU may shift its 
attention away from the audio tasks for one or two seconds. 
Therefore, more than t wo seconds of audio Ls typically buff- 
ered in system memory, (Actually, the user can vary the size 
of that buffer if necessary. A system that is often heavily 
loaded might need a larger buffer.) 

Two options exis* for moving audio data between system 
numory and the audio hardware. Either the CPl ' can move 
it in response to an interrupt, or the audio hardware itself 
can move it. Since the CPU often turns its attention to other 
tilings, it might take several milliseconds to respond to an 
interrupt. Under the design philosophy described above, the 
audio hardware would need to buffer enough data to cover 
that delay. To provide adequate storage space, a separate 
memory chip would he required, making the audio hardware 
somewhat more expensive. On the other hand, the audio 
hardware could access the data using direct memory access 
[ DMA) Tn perform I )MA. the audio hardware must become 
the master of the system bus. The delay for getting master- 
ship is on the order of tens of microseconds, and the buffer 
must be able to cover thai delay The DMA approach re- 
duces the size of the buffer by two orders of magnitude, In 
fact, in the final design, the required buffer size is small 
enough to implement inside a simple gale array (see Fig, 3). 
The gate array is required to interface to the bus anyway. 9* i 
the cost increase was negligible. Of course, the DMA logic 
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added design complexity: Thus, cost was reduced through 
increased R&D effort. To make the audio hardware inexpen- 
sive enough to offer it as a standard feature, the engineering 
trade-offs had to favor lower cost 

Physical or Virtual DMA? 

All modern workstations employ a virtual memory system 

that allows the CPU to work with virtual memory spaces that 
are larger than the physical memory available In the system. 
All programs access memory using a virtual address* and the 
CPU hardware translates it to a physical address. In con- 
trast, DMA accesses do not go through that same hardware, 
m i the hardware initiating a DMA request must supply the 
physical address to the bus. In that sense, HP workstations 
do physical DMA, not virtual DMA Still, an I/O device could 
include the hardware necessary to do virtual-to-physieal 
translation, effectively giving that device the ability to do 
virtual DMA Since programs work with virtual addresses, 
they could communicate with I/O hardware more easily if 
that hardware did virtual, rather than physical DMA 

Unfortunately, virtuai-io-physical translation hardware adds 
complexity and cusl ir» I/O hardw T are. For that reason, our 
audio hardware does not do virtual DMA. Instead, the driver 
software assumes t lie responsibility of presenting the hard- 
ware with physical addresses. Again, the trade-off was made 
in favor of lower system cost. 

Hardware Components 

Fig, 3 shows a block diagram of the audio hardware compo- 
nents within a simplified representation of a workstation. As 
shown in the figure, the audio hardware connects to the 
workstations system bus. lite CPU uses the system bus to 
initialize the audio hardware with the desired parameters 
such as sample rale, volume level, and so on. The DMA 
block uses the system bus to read audio data for playback 
and to write audio data for recording. It writes the playback 
data into the playback FIFO and reads the recorded data 
from the record FIFO. Each FIFOs size is 8 words by 32 
bits. The olber ends of the FIFOs connect to the serial inter- 
face block, This hardware converts audio data from parallel 
form, which the FIFOs use, to serial form, which l he audio 
CODEC requires, The term CODEC is an abbreviation for 
coder/decoder. In this context, analog-to-drgital converters 
are called coders and digital-to-analog converters are called 



decoders. The audio CODEC implements two converters of 
each type in a single chip, allowing stereo operation. Some 
of the CODEC inputs and outputs are buffered with analog 
amplifiers. In some cases, the amplifiers provide more gain, 
while in others they help match input or output impedance. 
The CODEC also implements the logic required to support 
the various sample rates and data formats discussed earlier 
The analog-to-digital and digttal-to-analog converters mher- 

i >perate with 16-bit linear data So. if A-law or jt-iaw 
mode is selected, the CODEC converts playback data from 
the selected mode to Iti-hil linear and recorded data from 
16-bit linear to the selected mode. 

The CODEC is a commercially available part. A single gate 
array implements the rest of the logic in the audio hardware. 
Some salient features of this HP-designed gate array are: 

4. Agates 

1.0-micrometer technology 

120 PQFP (plastic quad flat pack) package. 

The process used fdi this gate array allows Emer-pitch I/O 

pads than most similar processes. The liner pitch is better 
Munched to the particular ratio of gates to pins of this chip, 
[f manufactured in another process, this chip would have 
cost more because of a larger die area. 

Conclusion 

For audio to be useful on the desktop, audio capabilities 
must be pervasive, The HP 9000 Series 700 workstations 
have kept the cost of audio hardware and application devel- 
opment low by avoiding special-purpose hardware like digital 
signal processors in favor of using the power of the PA-RISC 
processor to handle digital audio signals. This allows HP to 
ship high-quality audio with every workstation. Our audio 
offering is completed with an audio server and basic audio 
tools to get users started with audio, and a library contain- 
ing audio widgets, a toolkit, and program examples for 
application developers. 
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Video Support in a Multimedia 
Environment 



Combining video with the computing power of a workstation adds an 

extra level of interpretation, detail and perception to information seen 
and manipulated on a workstation desktop. 

by Craig S* Richard 



We have all heard I lie expression "a picture is worth a 
thousand words," Images convey meaning that is difficult to 
express just using words. For example, consider the diffi- 
culty in trying to describe in words a person's looks, a shade 
of color, a Complex object, or a CAT-sc an image. You can use 
a lot of words to create a mental image of the object being 
described mid hope that the words are interpreted as you 
intended, or you can show a picture. Video takes the value of 
images a step further by presenting 30 interrelated pictures 
every second. 

We live in a lime when video Ls one of our primary sources of 
information. We depend on video on a daily basis to provide 
us with the information we need or desire. The television set 
is the focal point of many homes. We watch television to see 
the latest breaking news, to see what the weather is going to 
be like the next day, to see places and things that we may 
never he able to see In person, and simply for entertainment. 
Video gives us the perception of "being there" as we watch 
it. We experience the event rather than create our own inter- 
pretation of it, and we remember the experience in more 
detail. 

Why Video on a Workstation 

Obviously, b uy i ng ai i e x pe i is i ve workstatio n j 1 1st t o w a 1 1 i i 
television reruns, sports events, or any other broadcast tele- 
vision shows doesn't make a lot of sense. So why would it 
be useful to have \irleo on a workstation? A simple answer 
is that video can add a new dimension for doing many kinds 
of work. For example, consider a mechanical test engineer 
who must validate a computer simulation based un the de- 
sign data with the actual physical behavior of a mechanical 
part. Typically, this is done by first analyzing the behavior of 
the mechanical part on the computer using a 3D modeling 
package. By having the physical behavior available as video 
information on the workstation, the mechanical part can be 
simultaneously analyzed with its computer model The accu- 
racy of the analysis and the ease and efficiency of testing 
would be greatly enhanced This is just one example of the 
advantage of having video functionality integrated into a 
workstation, and the added value thai computers can bring 
to video, 

Using a computer is inherently an interactive experience. 
The user provides input through a keyboard, a mouse, or 
some other input device and the computer responds, takes 
some action, shows the results of thai action, and waits for 



the user to provide more input. Watching television is a pas- 
sive experience. The viewer typically doesn't interact with 
the picture on the screen. 

As computer technology and television technology con- 
verge, the result is the power and impact of video with the 
control and interactive capability of computers, This is 
where the advantages of video capability on workstations 
become apparent. By combining text, graplues, audio, and 
video into an interactive presentation, the user can quickly 
and efficiently gather information on demand with a high 
rate of retention. This is invaluable for on-the-job training 
where an employee may m^d to leani (or re I earn) a very 
specific task very quickly, As an example, take mi automo- 
bile assembler who may work on engine assembly for a few 
months and then work on front-end assembly for a few 
months, and so on. This is a situation in which interactive 
video and workstation capabilities can be combined with a 
computer-based training course to provide some quick and 
inexpensive training as the assembler moves from one type 
of assembly station to another. 

Challenges in Video Technology 

Although video provides a vast amount of in formation , the 
delivery of video also requires a vast amount of digital data. 
A video image on a monitor is composed of hundreds of 
thousands of dots of phosphor (pixels) that are illuminated 
(at different intensities) by an electron gim as it scans across 
t he monitor. The gun scans horizontally across a line of pixels, 
and then skips down to the next line and scans horizontally 
across the new line until the entire monitor is scanned The 
electron gun then jumps hack lu the tup of the display and 
begins scanning across the lines again. The whole process is 
repeated 30 to 75 times a second depending on the refresh 
rate of the monitor 

For television, the intensity of each pixel is determined by a 
voltage representing an analog signal received from a video 
source such as a VCR or cable TV tuner. The signal changes 
continuously to represent the color and intensity of each 
pixel. 

In the computer, the intensity of each pixel is determined by 
a voltage representing a numerical value in a specialized 
computer memory called a frame buffer hi a simplified 
black and white model, there would be one bit of memory 
representing the intensity of each pixel. If the bit is on, the 
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pixel on the monitor would be white, and if the bit is off, the 
pixel on the monitor would be black. More information is 
required to represent color images. To display 256 colors 
simultaneously (the most common workstation graphics 
capability), eight bits of information Ls required for each 
pixel. To represent true color (four million colors!. 24 bits 
of information is required for each pis 

To change the color or intensity of a pixel u value 

must be written into the frame buffer memory location that 
represents that pixel. Pot static, computer-generated images 
such as lext and graphics, the memory values do not need to 
be updated frequently. The border around the window, or 
the icon on the top of the screen may not change for hours, 
However, for animated sequences, the memory values repre- 
senting the pixels need to change for each new image. For 
video, this means that the memory value for each of the hun- 
dreds of thousands of pixels has to be changed 30 times a 
second! In the United States, there is a standard video timing 
format, NTSC (National Television Standards Committee), 
which allows for a video image that is 640 pixels \mi h< ai id 
480 pixels high. If the NTSC signal were represented in true 
color, there would have to be three bytes of information for 
each pixel. This corresponds to 900 K bytes of information 
for each image, and with images changing 30 times per sec- 
ond, over 26M bytes of information would need to be written 
every second. This is an enormous amount of information to 
move around every second, 

HP VideoLive Requirements 

Video teclmology in HP MPower has been provided by HFs 
VideoLive product VideoLive was developed by RasterOps 
Corporation exclusively for HP. HP engineers specified the 
requirements for the video capability, and RasterOps de- 
signed and produced a produd llmi met the requirements. 
Then' #ere four main design requirements- The first require- 
nn-jii wa> [<» provide full-ntol.ion (30 frames per second) 
video in a window on an HP 9000 Series 700 Workstation 
monitor. The window had lo be movable to any position on 



Ihe display, uniformly scalable, and oecludable by other 
windows on the display. 

The second requirement was that the video product had to 
work with existing HP graphics subsystems. At the time, 
most video implementations required a frame buffer that 

shared by the graphics and the video. HP prod 
some of the taghest -performance graphics frame buffers in 
the w odd, and nobody would be willing to sacrifice high- 
performance graphics for video functionality. 

The third requirement was that displaying video images 

id not adversely affect system or graphics performance, 
if the CPU were required to display video information, the 
system would need to allocate most ( if not all) of its process- 
ing power to the video. In a shared frame buffer implementa- 
tion, even though the CPC is not rendering the video, there 
is contention between the OPl and the video when the frame 
buffer memory is accessed, resulting in the degradation of 
graphics performance. 

The fourth requirement was that although watching video on 
a workstation has definite value, the ability to capture the 
video information has even more value. Therefore, it had to 
be possible to capture individual video fi-ames in digital form. 

VideoLive Hardware 

To meet the design requirements, an analog mixing scheme 
is used to generate video frames on the display, VideoLive is 
a single slot EISA card. The card has an on -board I024-by- 
512-by-24-bit video frame buffer into which an analog video 
signal is digitized in real lime. The digitization is accom- 
plished using a Philips SAA7191 video decoder and an 
SAA7192 color space converter The contents of the frame 
buffer are stored in RGB format (8 hits of red, 8 bits of blue T 
and 8 bits of green). A Riookuee Bt463 digital -to-anaiog 
coins He? { RAM I »A< ) is used to generate the analog signal 
lhal drives the monitor Fig. I shows Ihe architecture for the 
VideoLive card, 



Composite 

Video 
Connectors 




System Bus 



HP mm 

Graphics 
Subsystems 



Graphic 
a ltd Video 
RGB Output 



Fig. L, Si]ii[>[ii'iiT] block i Ingram 
d ur \ i to Live bardi 



)Copr. 1949-1998 Hewlett-Packard Co. 



April i l.m I k' wlf r th?m kard Joutt laJ b9 



The RGB output from the graphics frame buffer's RAMDAC 
is connected diroi tly to the Videotive card instead of to the 
monitor. Using a high-speed multiplexer, the RGB output 
from VideoLives video frame buffer is mixed with the RGB 
output from the graphics frame buffer A set of program- 
mable registers are used to specify Ihe position and si>se of 
the video window, 

The need to capture digitized video frames is met by digitiz- 
ing the analog video in real time into a frame buffer When 
grabbing frames, the video image is momentarily frozen in 
the video frame buffer and then the CPU reads the contents 
of the frame buffer (in RGB Format) over the EISA bus and 
into system memory. 

By taking advantage of the IIP Image Library capabilities, die 
captured frames can be saved in a TIFF file and can opt ion- 
ally be compressed using the JPEG compression algorithm. 
Once in TIFF 1 format, the captured frames can be printed, 
faxed, and viewed by IIP Image View, and pulled into the HP 
SharedX Whiteboard application to be viewed and anno 
lated over the network by several people. HP SharedX arid 
Whiteboard are de scribe d in the article on page 23 and the 
HP Image Library is described in the article on page 37, 

X Video Software 

Live video functionality is tightly integrated into the HP WE 
environment. This is accomplished using the X video exten- 
sions (Xv) to the X window server (see Pig. 2). Xv is a de 
facto standard for providing Uve video functionality For 
applications based on the the X Window 1 System. 

Xv provides the hooks through which X window geometry 
events such as position c banges and clip rectangles can be 
relayed to the video window. When an Xv window is active. 




X Video 
Extensions 



Fig. 2. t ,!JienT/st ner architecture and interface points to the video 
hardware and the workstation display, 



all geometry events to that window are intercepted by the Xv 
software. The Xv software renders a black area on flit 1 
screen onto whicb the video is overlayed. Xv also programs 
the registers on the video board to position, size, and clip 
the video, 

Xv also provides a programming interface that allow T s an 
application to control the video. The interface provides basic 
control of turning the video on and off, freezing and capturing 
video frames, selecting active video connections, and con- 
trolling video attributes such as brightness, contrast, hue, 
and saturation. 

Collaboration Using Video Images 

As previously mentioned, captured frames of video can be 
used by any of Ihe image-capable components of HP 
M Power. This functionality provides powerful collaboration 
capabiliLies, How many times have you been on the phone 
trying to describe a physical object to someone and wished 
that they could see the object? For example, consider a 
technician working with a prototype printed circuit board. 
As frequently happens during early hardware development, 
a few wires are put on tile board to fix layout problems. Sup- 
pose the technician is having some problems with the board. 
The technician contacts the design engineer and describes 
the problem. The engineer says the problem sounds like a 
problem that was fixed in an earlier release of the board. 
The technician and the design engineer can try to lix the 
problem over Ihe telephone, and if that doesn't solve iln 
problem, either the board or the design engineer must make 
a trip to fix the problem. 

If both the technician and the design engineer are equipped 
with workstations running IIP MPower and live video capa- 
bility, the technician can point a camera at the defective 
board or a specific area of the board and capture a frame and 
save it to a TIFF file. The TIFF file ran then be dropped into 
the HP SharedX Whiteboard and the engineer and technician 
can share the Whiteboard image. Tbe engineer circles the 
areas where changes w T ere made and show T s the technician 
how to make the changes. 

Tins is a specific example which can be extended to any 
situation in w'hich someone is trying to convey information 
about a physical object 

Conclusion 

As Computer technology and computational power continue 
to progress, the capability of processing video information 
becomes more feasible and less expensive. Video boards are 
now available from third patties that provide similar func- 
tionality' to the Vkleolive board, with the additional capabil- 
ity of capturing the video data in real time (30 frames per 
second ) and saving the digitized video on disk, HP has re- 
leased a software digital video player that plays MPEG en- 
coded video files from disk at up to 30 frames per second 
without additional hardware (see "Digital Video in HP 
MPower/ on page 8). 
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Mail Facilities in a Multimedia 
Environment 



Providing a multimedia email facility required that the well-established 
processes of creating, sending, receiving, printing, and replying to email 
messages be maintained and applied to messages containing multimedia 
objects. 

by Robert B. Williams, Harry K. Phinney, and Kenneth L, Steege 



The advent of tools and capabilities that allow users to 
manipulate and create rnukiiiiedia objects on a workstation 
mandated the need to make it possible to send these objects 
through electronic mail, or email. The user interface for 
Cresting, reading, and sending text messages through email 
is well-established. For multimedia email to be effective the 
same sort of pn k ess flow must be in place. For example, 
just as a user can use the more command to view a standard 
text email message, an equivalent faculty must be available 
to view T a multimedia email message. What this implies is 
that the user should not have to be concerned with invoking 
the correct software to deal with a particular media type 
because this should be handled by I he mail facility. 

The HP MPow F er mail facility, w r hich is represented by the 
envelope icon on the HPMPow T er front panel provides 
support for sending, replying, viewing, and printing of 
multimedia mail. 

For sending multimedia email, HP MPower provides two 

approaches: dragging and dropping a file on the envelope 
icon or clicking on the envelope iron. Willi ihe drag-and- 
drop met bod, rli< usei is presented wilh I he dialog box 
shown in Fig la From this box the user em i eh her send the 

dropped file io its destination by selecting the Send button or 

i hi' file by selecting (he Edrt bulhm. Iflhe Edit button is 
selected, the mail composer (editor) window is displayed 
showing t he contents of the 1 i : ls dropped on the 

mail icon (see Fig. lb). 

To read mail the user can click on the mail icon and be pre- 
sented with the two windows shown in Fig. 2. The firsl V 
dow contains the standard elm screen and the other contains 
the HP MPow r er viewer screen, Elm T which is ihe I IP i X 
screen-oriented electronic mail processing system, provides 
the user interface for the user to interact with the HP 
MPower mail system. To edit or create a multimedia mail 
message, the user can access the UP MPower mail editor 
(composer) by selecting MailMsg from I he elm screen. This 
will provide I he screen shown in Fig, lb. 

To read or view a mail message, ihe user would select nne nf 
the messages in die message lisl and then press ReattMsg 
menu item from the aim screen shown in Fig. 2* The selected 
mail message will appear in Che HP MPower viewer window 
for reading. 
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HP MPower Mail System Components 

The main components of IIP MPower mail include Ihe 
HP-UX elm mail user agent, a multimedia editor, several shell 
scripts, a standard multimedia file format and supporting 
software, and HP MJE actions and file types. Kig, :j shows a 
simplified diagram of some of the main HP MPowfr mail 
components responsible for providing ihe user interface 
actions d escribed above 

With the exception of vuemime. which among other things 
handles the encoding and det udam <if imiliimedia data, the 
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1 Nov 18 SEE ta.i.1 1 yocter (7210) Message from Margaret 

3 Jan 10 Robert IS. Williaflie (15) 
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You can use any ot the following commands by pressing the first character; 

Djelete or U)nde1ete mail, M)ail a message, R)eply or F)orward mail, Qjuit 

To read a message, pre^s <retuni>. j = move down, k = tnove up, ? = help 
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^Tils is the MalJViewer Window. It is the companion window to the Mail window. 

When you choose a tile to read in the Mail window, the message is displayed 
here. You cannot edit the contents of this window. 
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components shown in Fig. 3 that send or receive data re- 
quire no specific knowledge about dealing with multimedia 
data. For example, when a media-rich file is sent to sendmail, 
i lie file is treated like any other file going onto the network. 
Another example is when the composer or viewer needs to 
render a multimedia object (e.g., play an audio file or draw 
an image), the media icon is mapped to the process (or ac- 
tions) capable of handling the particular media object by the 
IIP VUE action database. 

Vuepad. This is an enhanced version of the HP VUE editor. It 
provides two modes of operation in the HP M Power mail 
system: composing (creating a multimedia mail message to 
send) and viewing (reading a multimedia mail message). 
Vuepad is described in detail later in this article. 

HP VUE Action Database. When a particular file type is selected 
the HP VUK action database provides the mechanism for 
invoking the appropriate action associated with that file 
type. For example, when the user double-clicks on an icon 
representing an audio file, the HP VUE action database tells 
vuepad that the audio player should be invoked to play the 
contents o!' the file. 



MIME, Vuemime, and MetamaM. To handle the interchange and 
storage of different types of data, HP MPower uses an inter- 
net standard known as MIME (Multipurpose Internet Mail 
Extensions). MIME is an extension to the basic internet mail 
standard RFC 822, which specifies the format for internet 
text messages. MIME defines the format for multipart, multi- 
media mail messages, Vuemime and metamail are utilities that 
provide support to PIP MPower for MIME data. Vuemime pro- 
rides a single interface for HP MPower components using 
NOME data, and metamail is a public-domain ulility thai we 
modified to act as a MIME filter. In Uiis role metamail decodes 
and flattens MIME messages from non-HP MPower sources 
and encodes messages going to the mail transport agent 
send mail. Vuemime is the only HP MPower component that 
communicates directly with metamail. MIME, vuemime, and 
metamail are described in more detail later in this article. 

Mail User Agents, HP MPower has two mail user agents, elm 
and a shell script called mmsend. Efm is the main user agent, 
providing the usual elm capabilities of viewing, printing, 
saving, or deleting incoming or stored mail, replying or for- 
warding mail, and originating mail Elm is the standard mail 
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\ u-« nessor that is shipped with every HP workstation. This 
greatly reduces the support load and avoids duplication of 
development effort. Unfortunately it also put us in the posi- 
tion of offering a keyboard-based mail agent amidst a large 
collection of applications with graphical interfaces. Access 
to elm is through clicking on the mail icon, producing the 
screens shown in Pig. 2. 

I >rir of the obvious changes to elm's normal interaction mm li i 
is i he io« As used to view and edil mail, hi the HP MPower 
environment! Since we have to deal with mail that may con- 
lain nontextual items, the multimedia composer [editor) and 
\ iewer in vuepail arc usvi\ id edil and view mail, This is done 1 
by modifying the users eimrc (configuration) file so thai 
instead of invoking vi or more for editing or viewing a file, I II* 
MlWers editor or viewer are invoked. Most other user cus- 
tom izations of elm behavior in the elmrc file are preserved 

Tin' second mail user agent, mmsend, provides an interface 
for drag and drop mailing of multimedia objects. Dropping a 
file or files on the mail icon causes the software to invoke 
an HP VI IE action that indirectly calls the mmsend shell 
script Mmsend drives the processes thai are responsible for 
displaying and interacting will* the screens shown in Fig. I. 
The mmsend script also invokes the processes dial convert 
multimedia files into MIME format. When the user selects 
I he Send button from the mail dialog box shown in Fig, l r 
mmsend invokes the mail transfer agent sendmail to dispatch 
the message over the network. 

Mail Transfer Agent. The primary mail transfer agent in the 
current version of HI' MPower is sendmail, die IIP I X facility 
for sending mail over the internet. All hough there are gate- 
ways from sendmail SMTP (Simpii Mail Transport Protocol) 
to X. 400 and Open Mail these gateways are not supported 
because ihev have mil been enhanced to understand MIMK 
on the SMTP (outbound) side 



Instant ignition systems (see page 17) usually do not have 
sendmail enabled. To overcome this the HP MPower inslalla 
lion scripts set up a default sendmail.fc and alias database. 
This is only done if sendmail is not already enabled. It dm- 
noi address sendmail connectivity issues in complex or re- 
stricted environments. Ideally, sendmail would be turned off 
on minictient systems because the mail agent runs on the 
server with the rest of HP VUE. 

Printing. Multimedia printing involves decomposing the MIME 
formatted Hie into its pails and invoking the IIP MPowei 
print action (HP Shared Print ') on each of t tie parts. HP 
Sliniedprint is described m die article on pap- 11 Envoking 
\U l SharedPrint Tor mall is handled by the shefl script mmphni 

Several types of multimedia cannot be printed (e.g., audio 
files). This is handled by a print action for the unprintable 
file that maps to the special action none. 

Since printing actions happen on the client (HP SharedPrint 
Forces lhis) 1 vuemime arid its database mimetypes must exist on 
the client as well as die server. This has implications for 
installations adding multimedia types. 

Mult i media Editor 

An important aspect oi a multimedia mail facility is the ability 
to compose and view documents containing both text and 
nontextual items. In the HP MPower environment this abil- 
ity is provided by a specially evolved version of the HP VUE 
text editor, vuepad.t All of the multimedia editing and view- 
ing facilities available in HP MPower are built on this new 
version of vuepad. 

The development of this component was constrained by 
many different factors. The schedule u asset to allow the 

t Unless stated otherwise rrfei omas to vuepsd in the rest of this article will be ttf erring to the 
new version eJ I he program 
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introduction of the product to coincide with I he release of 
iu u workstation computers. This ensured good public expo- 
sure for the product, but limited Ore amount of time and the 
number of engineers available for product development. The 
schedule and staffing level provided a strong motivation for 
using the functionality of existing products rather than 
wholesale developmehl ol new components, 

Vuepad Modes. The vuepad program provides two modes. ( tae 
is the HP M Power mail composer (mentioned previously) 
for creating and editing multimedia documents. The other 
mode is the HP M Power mail viewer (also mentioned pre- 
viously) for viewing or listening to multimedia documents. 
The viewer is simply a read-only version of the composer. 
These facilities are accessible from the HP MPower mail 
icon or the IIP VUE panel edit icon. The activation of either 
of these two modes is determined by the arguments passed 
to the vuepad program when it is invoked from the mmpad 
script shown in Fig, 3. 

The HP MPower mail composer takes files created by the 
various media editing tools such as the HP SharedX White- 
board or the audio editor and allows the user to incorporate 
the files generated by these tools into a document contain- 
ing text. The final oulpul of a message created by the com- 
poser is in a formal compatible with die MIME standard. This 
approach required no modifications to any of the media edii 
ing tools and no changes to the core email application (elm). 
Use of the MIME message format helps provide some inter- 
operability with other mail systems and gives us access to 
an already well-documented and carefully defined structure 
for messages- 
Fig. 1 shows that the vuepad editor provides the composer and 
viewer with a visually appealing "iconic' 1 view of nontextual 
data. The vuepad editor ensures that a user's normal editing 
actions function as the user expects in the presence of non- 
textual items. It also ensures that the operations available 
for manipulating nontextual items are clearly visible. 

Modifications to Vuepad. The required modifications to the old 
vuepad editor included adding the ability to invoke a filtering 
program for reading and writing multimedia data. The choice 
to do this filtering in a separate program was primarily driven 
by the need to develop the filtering functionality In parallel 
with the enhanced editor, and a desire to use different de- 
velopment progranuning languages for the editor and filter. 

The filter is the vuemime program mentioned earlier. When 
vuepad is reading a multimedia file, vuemime strips out. the 
media data, writing each media object to a separate tempo- 
rary file. The media data is replaced within the original data 
stream by a special character sequence indicating that a 
media object existed in that location. This character se- 
quence, known as a tag, eon tains the name of the temporary 
file that holds the media data. This file is used by vuepad and 
the IIP VUE file-typing facilities to determine the graphical 
Leon lo display in place of t lie media object When vuepad 
writes to a multimedia file, vuemime inspects the file for any 
lags and replaces the tags with the actual media data and 
the necessary MIME header information. 

It was necessary to augment, or override some of the inter- 
nal functions of the OSF/Motif text widget that vuepad is 
based on. Before the widget draws a line of text, vuepad 
checks to see if the text corresponds to part of a media icon. 



If it does, then vuepad draws the necessary portion of the 
icon. If the text does not. contain pan of an icon, then the 
text widget is allowed to render the whole line of text 
Whenever the widget writes or reads data to or from either 
[he OSF/Motif clipboard or the X primary selection window 
fa clipboard thai can hold one item ul a limej, vuepad runs 
the data through the vuemime filter program to reinsert or 
strip any embedded media data as required. When the user 
selects a portion of text for an editing operation, vuepad tracks 
the selected region to provide meaningful highlighting of any 
selected media icons. Vuepad also observes all deletions hi id 
additions to the document to accurately track the position 
of i he media objects within the document. Special care is 
also taken during the spell cheeking and formatting opera- 
lions. The spell checking code must exclude the rather cryp- 
tic media tag data from the text sent to the spell checking 
program t and the formatting code has to do its work while 
preserving the relative locations of the media icons* 

Compatibility. The behavior of vuepad is controlled by X 
Window System resources and command line options ilmi 
allow vuepad to behave identically to the previous nonmedia- 
enhanced version of the IIP VUE editor. The HP VUE file 
typingt and action database mechanisms were used to 
speed development and to provide consistency with HP 
VUE T s Hie manager appearance. The HP VUE action data- 
base provides a simple means for invoking an appropriate 
action associated with any particular file type. Use of the 
action database in vuepad ensures consistency with the de- 
fault action accessed from the file manager for a particular" 
file type. 

Composer Features. The IIP MPower multimedia composer 
presents a flat, scrollable view of a document. This allows 
the user to access any and all document parts rapidly with 
no enforced sequential ordering. The media objects are em- 
bedded in the document, that is, the actual media data is 
copied into the resulting file rather than having links main- 
tained to the original data. This ensures that the recipient of 
a message not only has immediate access to the data, but 
also results in larger messages and freezes the data at the 
time or composition. The media ohjeets can be embedded at 
any location within the document, providing significantly 
more flexibility than the "attachment* model used by many 
mailers. The attachment model main tains links to other 
parts of a document. 

To incorporate a media object into a document being com- 
posed, the user can either use the Include dialog facility of 
vuepad or drag the object from a file manager view and drop 
it on the composer's window. If the user wishes to create a 
new media object while composing a message, the appropri- 
ate editing tool (e,g, T the audio editor or the image editor) 
must be used to create the object within that editor. After 
the media object is created and saved in the file system, vue- 
pad s Include dialog or drag and drop facilities can be used to 
include the new object in the message being composed. 

As shown in Fig. 1, the composer displays icons in place of 
all nontextual portions of the document. This results in a 
reasonably attractive appearance and good user recognition 
because of the similarity svith the IIP WE file manager 

t The HP VUE liCa typing mechanism provides the capabsfrty to define classes ot files. For 
example, it can define all fifes ending wrth tf to be of class tut 
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iconic view. The user can either double-click with the mouse, 
i *r press the Return key to activate the currently selected 
icon. This provides a simple and quick means of viewing or 
playing the media item and allows easy access from uV 
board For those users who p refer not to move their hands to 
the mouse, 

The composer also provides an Actions menu item which is 
sensitive whenever a single media item is selected. This 
menu contains two it puts. The first item is Open, which dupli- 
cates the functionality of double-clicking on the selen 
icon. The second item is Save As, which allows the user to 
save the selected media object to another file separately, 
with no MIME structure. Tile Save As action is also the de- 
fault "'open" action of the unknown data type. The unknown 
data type allows users to pass arbitrary binary data through 
the mail system undisturbed. 

The riinviii ini; >]< mentation of the composer does have 
some limitations, but a foundation has been built upon 
which to improve and add features to the current version. 

Multimedia Data Extensions 

As mentioned previously, HP MPower supports the inter- 
change arid storage of several different types of multimedia 
■ tat ii contained in a single message or a file via a format con- 
forming to an extension to internet mail known as MIME 
(Multipurpose Internet Mail Extensions). This multipart, 
multimedia support is implemented in HP MPower by two 
utilities: metamail and vuemime. Metamail is a public-domain, 
sample implementation Of S full-featured MIME agent. Vue- 
mime is a MIMB filler that was created specifically for HP 
MPower and HP V1TE to simplify general ion and manipula- 
lion of multipart, multimedia data from the various HP 
MPower components. 

We selected MIME for its strong support within the int.ernei 
mail community, and we found it («> hi- ;tlso useful outside 
the mail domain. The HP VI Mower environment recognizes 
files structured in compliance with the NOME speei fir at ions 
and will deal with them transparently for editing and printing. 
The composer allows the user to insert nontextual objects 
into any document being edited, and ihe resulting file will be 
saved in MIME format. The MIME message formal is also 
used forcul and paste operations between editing windows. 
This allows the USer tO neat editing of mixed-media data in 
the same manner as plain text. Unfortunately, the mail com- 
poser is currently the only application that understands 
MIME data in cut and paste operations. 

Tltis section first provides some background on MIME, 
describes metamail in the GCKtted df HP MPower, and t« 
discusses vuemime in some detail, 

MIME Background. Since 1982 the standards that to$m the 
basis for interne* mail haw been defined by l*K< S22 and the 
SMTP f Simple Mail Ti;uispoi1 Protorul) defined by RFC S21.I 
RFC 822 was intended u> specify a format fur lexl messages 
and, as such, did not explicitly allow For inclusion of multi- 
media messages such as audio or image data. In particular, 
RFC ' 822 defines a message as consisting of two parts: a 
header and a body. The header consists of a series of specific 
field names and field values followed by a blank line that 

" l.ii.'. ini'i'i i .,-ii^rrt is defirecl by ortB or more sianriarris e,,. ' Re^&Stfel 

ijiirimant. or RFC. 



marks the end of the header and the beginning of the body. 
The body is restricted to relatively short lines (1000 charac- 

of seven-bit AS( U characters which cannot exceed a 
t ertain length. I'sers who wish to include nontextual data 
have to convert the data to seven-bit ASCII before submitting 
the data to their mail user agent or mail program. 

RFC 1049 attempt ed ro rectify 1 some of the deficiencies of 
RFC S22 by defining a header field and a content type that 
marks the entire message body as being a certain type of data 
(e.g., text, audio, video, etc.)- bi the absence of a content- 
type fiekl the body was assumed to be I ".S, ASCII text 
before. Although RFC 1040 has been used by several imple- 
mentations, it is not without problems. The most severe 
problem is its total lack of support for multipart mail RFC 
1049 allows a message body to be specified as containing 
something other than text, but only one such thing, 

RFC 1341, or MIME, generalizes and extends RFC 1049 in 
several ways. Most important, it defines a new content type 
called miff ft purl, which can be used to encapsulate several 
body parts within a single RFC 822 message body. It also 
goes far beyond RFC 1049 in explicitly describing the set of 
allowable content types by defining a subtype mechanism 
for content types that includes provisions for addressing 
standardized encoding of non-ASCII character sets. It should 
be noted that RFC 1-341 is an extension to, rather than a 
revision of RFC 822 in that it defines these new features 
(including lex I of unlimited line and overall length, charac- 
ters sets other than ASCII, and multifuni messages) within 
the confines of RFC 822. 

The new 7 header fields and content types defined in the 
MIME extension are described on the next page. 

MetamaiL Metamail is a public-domain, sample implementation 
of a MIME agent that was designed to function as a back 
end for an existing mail user-agent. It can be incorporated 
teito virtually any mail reading {or bulletin board ) program 
(e.g., xmail, xmh T elm, etc), enabling it to become a multimedia 
leading interlace. Metamail knows how to parse a structured 
MIME message, flat ten any hierarchy of nested messages, 
decode the- various parts, and optionally dispatch the appro- 
priate handlers or viewers for the different parts. The com- 
mands used to dispatch the handler or %iewer for each con- 
tent type are specified in one or more mailcap (configurai ion) 
files, whieh allow a great deal of flexibility in adding and con- 
flgttring handlers. As a viewer, metamail can be thought of as a 
multimedia counterpart to the ASCII paging tool more, exrept 
thai it enli id of additional handlers and viewers when 

paging through a message in a linear fashion, 

in HP MPower we needed more flexibility when composing, 
viewing, printing, and sending mail so we old not incorpo- 
rate metamail directly in our mail user agent (elm). Instead, we 
use the enhanced version of vuepad described above as our 
mail viewer and composer and we delegate metamail to the 
role of a MIME filter or preprocessor and postprocessor Jn 
this role, metamail serves primarily to simplify the digestion 
and generation of MIME compliant messages by other III 1 
MPower components. Specific -ally, metamail is used to llalten 
potential message hierarchies and to encode and decode 
each message pari according to its encoding scheme. On the 
input side (mail receiving), for example, ii we receive a 
MIME message from a non-HP MPower sender, we pass it to 



)Copr. 1949-1998 Hewlett-Packard Co. 



AprJJ 1904 Hewlett ■■I'jir-kf.irtl.lmiriKLl 75 



MIME Header Fields 



The MIME extension |RF 1341 1 to the basic internet mall standard RFC 822 created 

the following new header ffefds: 

• MIME Version This field is used to specify a version number thai declares a 
message conformant with The MfME standard 

• Content Type. This field is used to specify the type and subtype of data in the body 
of a message and to specify the complete encoding of such data 

• Content Transfer Encoding. This field is used to specify auxiliary encoding applied 
to data to allow it to pass through mail transports having data or character set 
limitations 

• Content Identjf ier and Content Description. These fields are used to further descrrbe 
data in the body of the message 

Content Types 

MIME enumerates precisely seven valid content types and requires that any addi- 
tions to this set be specified m a new, similarly formal document. This restriction 
is a major change from RFC 1 049, which allowed for much freer definition of new 
content types. Instead, the new mechanism for extensions is to define new sub- 
types of established content types, fn general implemented are required to regis- 
ter new subtypes with the Internet Assigned Numbers Authority (IAN A} to avoid 
name conflicts. (An exception is private subtypes begmning with the letter X, 
which can be used freely and without registration \ 

The seven defined content type values are; 

• Text. This is the default content type. The default subtype is plain text. This 
content type has a charset attribute that has the default value us-ascn 

• Image Th?s content type is for still images. Subtypes are image fnrmat names 
[e.g., image/gif and image/jpeg). 

• Audio This content type is far audio information. Subtypes are audio format 
names For example, audio/basic denotes single channel 8000-Hz u_-law audio 
data. 

• Video This content type is for video frames. Subtypes correspond to video fomiar 
names such as video/mpeg 

• Message, This content type is used to encapsulate an entire RFC 822 format 
message For example, it can be used in forwarding or rejecting mail. The stan- 
dard defines two subtypes of message: message/partial, which can be used to 
break a large message into several pieces for transport so that they can be put 
back together automatically on the other end, and messagefexternai-body. which 
can be used to pass a very large message body by reference, rather than including 
its entire contents. 

ft should be noted that a message with a message content type can contain a 
message that has its own, different content-type field, meaning diat the message 
structure can be recursive. 

• Multipart, This content type is used to pack several parts, of possibly differing 
types and subtypes, into a single RFC 822 message body The contem-type field 



specifying a multipart type also rncludes a delimiter, which is used to separate 
each consecutive body part. Each body part is itself structured more or less as an 
RFC 822 message in miniature, possibly cootainmg its own content-type field to 
describe its type. Subtypes of multipart fypesare specifically required to have the 
same syntax as the basic multipart type, guaranteeing that all implementations 
can successfully break a rnu Its part message into its component parts. An expected 
use of multipart subtypes is to add further structure to the parts and to permit a 
more integrated structure of multipart messages among cooperating user agents 
• Appltcation. This content type is for most other kinds of data that do not fit into 
any of the above categories, such as list servers, mail -based information servers, 
and PostScript ™ 

A separate part of the content-type header field can be used to convey supple- 
mental information that may he either optional or required, depending on the 
content type. Such parameters are given in keyword = value format, and are used, 
for example, to convey information about character sets for text objects. Thus, thn 
default message type for internet mail can be given a MIME content type of: 

Content-type: text/plain; charset=us-ascii 

Content Transfer Encoding 

If internet mail transport (SMTP, as described by RFC 821} rs ever upgraded to 
permit arbitrary binary data of unlimited line length m message bodiEs, the issue 
of encoding a message for transport will go away However, even those who 
advocate such changes to SMTP generally recognize that they will be slow in 
coming. In the interim, there is wide perception that a standard mechanism for 
encoding arbitrary binary data for mail transport is needed. 

The content transfer encoding header field can he used to specify the encoding 
technique used to render binary data in short lines of seven -hit data. After much 
debate, the working group settled on two encodings, which may be used inter- 
changeably One of them, the base-64 encoding, encodes each three bytes of 
binary data as four bytes of 7 -bit data, using a base-64 alphabet selected for 
maximum portability across SMTP implementations, including ASCII to EBCDIC 
gateways The other encoding scheme, quoted-printable, is a less efficient repre- 
sentation that preserves nearly all 7-to'rt ASCII characters as themselves. It is 
expected that base-64 will he preferred for genuine binary data, while quoted- 
phntable will be preferred for data that is largely US ASCII, but has scattered 
non-ASCII characters within iL In particular, this may he the preferred encoding for 
textual email in the national-use variants of ASCII, ISO 8859-X, 

If the content transfer encoding field appears Iri the RFC B22 message header, it 
refers to the body of the message if it appears in the header area of one part of a 
multipart message, it refers to the body area of that part only The content transfer 
encoding field is prohibited when the content-type field has a value of multipart or 
message. This is necessary to prevent nested encodings 



rnetamail, which filters it. hy Battening any nested message 
hierarchies and decoding each message part. The result is a 
Simplified MIME template that can be easily dealt with by 
other HP M Power components. On the output side (mail 
sending) rnetamail is used mainly to encode message parts for 
handling by the SMTP transport used by our mail transport 
agent sendmaiL While we can handle nested messages on the 
input side, we only generate flat. single-level messages on 
rlic output side. 

The official rnetamail documentation and software, including 
a draft of RFC 1341, can be found in the puh/nsb directory on 

thumper.bellcore,com. 

Vuemime. In HP MPower, interaction with MIME messages is 
not the sole domain of the mail user agent (elm) and its 
viewer and composer (vuepad). Since MLME is used as the 
storage format for all multipart, multimedia data, printing 



and sending MIME data as well as composition and vie wing 
have to be performed independently of elm. Printing and 
sending, for example, can be done by simply dropping a 
MTMK file on I he HP VUE front-panel printer or mail icons 
without invoking elm or vuepad. 

Vuemime was created specifically for HP MPower components 
to provide a single interface to MIME data and, as snch T vue- 
mime is the only IIP MPower component that directly enlists 
the services of rnetamail. Essentially vuemime can be viewed as 
a higher-level MIME filter wliich, in addition to providing the 
type of filtering performed by rnetamail, provides intermediate 
formatting thai is easily digested by various HP MPow<r 
components. What has resulted, after analysis of the needs 
of various HP MPower components, is essentially five levels 
of formatted data winch can be viewed as stages in a file's 
morphosis from raw data (level 0) into a fully formatted 
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level 3 IMIME Fife} 
Content -Type: mmlhpaH/ii ■ w t. 



Hime-VefSDA I J) 
Subject Visual Test 

—inn 

C— ient type mVplain 

Here s a Pictare ot a Tor 

-loo 

Coment type anaje/gil 

CtinteBHraitttef -ei ic otfitt a basgW 

0*JWABafiT»////9nZpbv/Mr»7 
dmtfbWZbtrn/oVffi 

-Ion 

Content HrpeiexL plain 

Con Ton Guess What Irs thtd For*? 
-Inn— 



• Parse as multipart mi ied 

• Handle teal inline 

• Convert to base -64 and save 
tnia temporary file m 
external body lormal 



Level 2 f Extern at-BorJv Format) 

aMfee-HjaeimO 
CdnfteM-fjfM' HnMiparVnuird 

Subteci Vrtuillesr 
♦po 

Cwtefil-TypeTcitpEa** 

Mere * a Picture ol a Toy 

-loo 

CowHinl l|pw awhi ■UHjiiiUiiiiat body, 
access-mode = local lit* 
filename = 'ui/lmp.aa gri 

Content type . imaqe g it 

-loo 

Cortmrt -type text/plain 

Cam You Guess What Its Used Fm?? 
-too- 



w 



Level 2 (Externa* Body Format} 

X VHBMimB-Lewel? 

ContM nl -Type: muilipnft/mtfted. 

boundary = foo 
Subject: Visual Test 

CnntenMypeiteaVplain 

Hide's a Picture ol a Toy 
-too 



Conient-ivpemusage^xlemal-boaY 
access-mode = local -tile, 
filename = /Li5r/lmp tea .gil ' 



Conlenl -type image/gil 

-loo 

C unl e rtl -tyoe.text/plain 

Can Vou Guess Wrist It's Used For?'' 
-loo.-- 



i Unroll MIME natation. 

' Replace external references 
in MIME format with simple 
one-line syntax. 



gil Image File 



Level t (Tagged format) 

Subject: Visual Test 
Here's a Picture nl a Toy; 
rnmtog ima ge/tj if/tisr /imp/aa gil 



Can You Guess What it's Used HtV 



iw 



Tag 



Level 1 (Tagged Format) 
Sub loci; VtsMtl Test 
Here's b Picture ol o Toy 
» mrntag im^ge/gil /im/tmp/iia git 



Can You Guess What its Used For?? 



Use HP VUI typing on tile name to 
determine icon and action 
Replace tag reference with icon. 
If user double-clicks icon, use HP 
VUE action to run viewer on raw 
data tile, 



git Image File 



Level _y 
(Raw Data File? 



Subject: Visual test 
Here's a Picture ol a Toy 



Doubleclick here to View 



Can Vou Guess What It's Used For™ 



(0 



FtK- L i''' i: '- I'HMiijj an incoming 
jiM-ss,- ' rtrtat 

and the actions of vuemime U 

aal 1 1 .■ Lev* i lffl\ i trmai 
an I I he actions performed bj 

fi rn the i. • 
.i level 1 represi i -i itfon I I 
Level- 1 He formal citation 

and the actions taken by Yuspad to 
! mm: and nontextual 

parts of the m^asa^e. 



MIME message ready to be handed off to the SMTP mail 
transport. 

Fig. 4 shows the steps involved in transforming an incoming 
message in MIME formal (level 3) through Mir various levels 
of formatted data to a tagged (level I ) format. Pojr an outgo 
ing message, vuemime will take a lagged message and gener- 
al e n self-contained MIME message Mi at Can l>e pasxd to 
the mail transfer agent. 

The live levels of formal ted data shown in Fig. 4 are defined 
aa follows; 



* Level ft. This is raw data consisting of ASCII text and tu m- 
textual information such as image, audio, and video data, 

* Level 1. I Jala ai this Irvel. which is used by vuepad and the 
romp rim action, is in a special lagged format that contains only 
ASCII text, summarized mail heading information, and spe- 
cial tag lines representing multimedia objects. The tag lines 
indicate die multimedia type and a path to a file containing 
the raw data. See the level! tile representation in Fig. 4c. 

* Level 2, This is an external-body £flg format- The format at 
this level isveq similar to level I except thai MIME header 
and control lines haw been added to make it fully MIME 
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compliant All multimedia objects axe still external (and 
raw) but are now identified by Content-type: <message>/ 
<extemal-body> and Content-type: <iype>/<subtype> lines. 
See the level-2 file representation in Fig. lb. 

HP MPower does not currently send messages in level-2 file 
format but this Je%'el could be useful in at least two situa- 
tions. First, levei-2 formal could greatly reduce the size of a 
message by not sending the actual contents of something 
like a video clip, hi this case, the video information is noi 
sent until and unless the receiver wishes to view the video* 
The other important use of levei-2 file format is to provide a 
"hot link 1 * to the current version of some data. For instance, 
a message might contain an external-body reference to 
some data thai is updated hourly. The receiver of the mes- 
sage would see valid data at the time the message is read, 
insi ead of t he data as of the time the message was sent. 

• Level 3. This is a MIME file. All references to external multi- 
media data files are replaced by encoded data. See the 
level-3 file representation in Pig. 4a, 

• Level 4. This is a MIME Hie with an outgoing mail address 
and header Information (from the mail user agent) prcpended 
to it. At this level the data file is ready to be transported l<» 
the network services 

Vug mime accepts command line options to transform data in 
either direction and between any levels from to 3. Level 4 is 
generated solely by the mail user agent (mm send) for outgoing 
mail. The HP MPower component (vuepacf) simply indicates 
to vuemime on the command line the level of the file being 
transformed and the level to which it is to be formatted, 

Vuemime generates only base-64 encoded data when going 
from a level-2 (or lower-level) file to a Ievel-3 (MIME) file 
even though it can accept other types of encoded data when 
going from a level-3 file to a lower level. Also, vuemime only 
generates flat multipart and mixed level-2 and level-3 mes- 
sages even though it can accept and digesi [vi;i metamaif) 
nested level-3 messages generated by a non-HP MPow f er 
MIME system, 

Mimetypes. Transformation to and from raw data by vuemime is 
controlled by a file called mimetypes. The mimetypes file is a 
cross between meiamails mail cap files and HP VUE's file-type 
definition files. Table 1 shows the contents of the mimetypes 
file supplied with IIP MPower 1.0. 

Vuemime uses the data in the Orst column to map levei-0 (raw 
data) files to the content type for files that are being trans- 
formed to a higher level. The third column is the content-cype 
value inserted in files of level 1 and above Ft* level -1 Bles 
and above that are being transformed to lev el-0 files, the 
column 2 entry associated with a particular content type is 
used to determine the file name extension to be applied to 
the new raw data file. 

Conclusion 

Our multimedia email project is an example of a highly 
leveraged effort that combined existing blocks of function- 
ality, some modifications, and new "glue* to meet a market 
need quickly. 





Table 1 




Contents of the HP MPower Mimetypes File 


Search Pattern 


File Extension 


Content-Type Value 


for Raw Data 


for New Raw 




Files 


Data Files 




.*Yxwd 


%s.xwd 


image/x-xwd 


Axd 


%s,xd 


image/x-xwd 


."Uif 


%s.lif 


fmage/x-iiff 


•Vtrff 


%siiff 


image/x-tiff 


Aeps 


%s.eps 


image/x-eps 


Apcl 


%s.pcl 


image/x-pcl 


*Vgif 


%s.gif 


image/gif 


■*Vjpg 


%s.jpg 


image/jpeg 


,*\.jpeg 


%s.j"peg 


image/jpeg 


,*\pm 


%s.pm 


image/x-xpm 


."Yxprn 


%s.xpm 


image/x-xpm 


*Ybm 


%s,bm 


image/x-xbitmap 


Axbm 


%s,xbm 


image/x-xbitmap 


Abmf 


%s,bmf 


image/x-bmf 


Aps 


%s.ps 


applic ati on/ PostScript 


AM 


%s.txt 


text/plain 


Aau 


%s.au 


audio/ basic 


AI16 


%sJ16 


audio/x-Unearl6 


AI8 


%sJ8 


audio/x-Linear8 


*%m 


%s.lo8 


audio/x-Linear-80ffset 


A.wav 


%s.wav 


audio/x-mfcrosoft-RIFF 


Asnd 


%s.snd 


audio/x-NeXT 


At! 


%s.u 


audio/x-Mufauv 


Aal 


%s.al 


aiidio/x-Afaw 


AZ 


%s.Z 


application/x-compress 


A.tar 


%s.tar 


application/x-tar 


Aunk 


%s,unk 


a pp lie ati on/a ctet-stre a m 



Ac kn o w J edgm ents 

The multimedia mail team offer a special thanks to Gabe 
Beged-Dov, a former HP engineer, for discovering the lever- 
age possibilities in the MIME internet standardization efforts, 

HP-UX is based on and is compatible with UMX System laboratories' UNIX* operating system. 
It also complies with X/Opens* XPG3, POSIX" 1D03.1 and SVID2 interface specifications 

UNIX is a registered trademark of UNIX System Laboratories he in the U S A. and other countries. 

X/Qpen is a trademark nf X/Qpen Cnmpany Limited in the UK and other countries 

PostScript is a trademark of Adobe Systems Incorporated" which mey be registered m certain 
jurisdictions. 
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A Fast and Intuitive Online Help 
System 

The HP Help System provides application developers with the tools to 
create and integrate rich online help information into their OSF/Motif- 
based applications. 

by Michael R. Wilson, Lori A. Cook, and Steven P. Hiebert 



With the growing complexity of today's UNIX*-operating- 
system applications, and live desire to improve usability, 
media-rich information is becoming more pervasive in 
today's computing environments. Users expect some base 
level of online help to be provided from Within the applica- 
tions they are using. They expert online information to be 
intuitive and graphical, with growing expectations of direct 
audio and video support and interactive capabilities. 

The HP Help System is a good start towards providing multi- 
media online information that is both fast and intuitive 1 . It has 
become the standard online help system within HP and ts 
used extensively by the HP VHP' and HP M Power products 
and many other OSF/Motif-based products 

Background 

The current IIP Help Developer's Kit is the second attempt by 
the ]\V VI K program to deliver an application help system 
for everyone Hie first version, HP Vuehelp 2,0, while satisfy- 
ing some of the HP vui\ requirements as m application help 
system, failed to meet application developers" requirements 
for features, performance, and ease of integration. 

One of the design goals for the HP Help System was to de- 
liver a complete solution to developers for creating, Inte- 
grating, and shipping rich online information with their OSF/ 
Motif-based application, while keeping its presence (system 
resource use) to a minimi mi. There is a very fine tine between 
providing the rich set of features that our customers require 
and maintaining our performance objectives. In 95% of the 
cases in which the issue of features versus performance 
came up, performance won. 

Based on the knowledge and insight our team gained in doing 
1 hr first version of the HP Help System, and a willingness to 
make radical changes in our second release, we basically 
started from scratch. We knew that our next-generation help 
system needed to provide a competitive set of base feat un 
and functionality that developers require, while producing 
little or no end-user-visible performance degradation to the 
hosting application. 

The Help Developer 1 * Kit 

The HP Help Developers Kit is a complete system for devel- 
oping Online help for any OSF/Molif-based application. It 
allows authors to write online help that includes graphics 
;uul text formatting, hyperlinks, ami rommuniratioii with 
the application. It provides a programmers toolkit allowing 
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Fig* L Hr'lfi dia(og widget 

developers to uiiegrate this rich online help information into 
their client application. The help dialog widget (Fig. 1) 
serves as I he main display window for the HP Help System. 
A second, lighter* weigh! help widget (quick help dialog) is 
also available in the toolkit. 

Following is a list of the components supported in the 
developer's kit; 

* For Authors 

The HP HelpTag markup language. This is a set of lags 

used in text files to mark organization and content of on 

line help information. HP HelpTag is based on SGML 

(Standard Generalized Markup Language), 

The HP HelpTag software. This is a set of software tools 

for converting the authored HP HelpTag files into run-time 

help files that contain the text, for the help messages 

displayed in the help widgets. 

The HelpVicw application, Thi> is :\ program that allows 

an author to test a newly developed online help facility 

• For Programmers 

Tlie Xvh programming library. This library provides an 
application programming interface for integrating help 
windows into an application, 
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A demonstration program. This is .« simple example thai 
shows how to integrate the HP Help System into an 0SF7 
Motif application. 

General Packaging Architecture 

An online help system Reeds Tu feel like it is part of the host 
application 10 the em J user; not an appendage hanging off to 
the side For developers lo leverage a third-party help system, 
it must be delivered in such a way as to provide easy and 
seamless integration into I heir application. Furthermore, the 
effort and overhead of integrating and redistributing this 
help system along with their application must be minimal, 
while at the same time meeting the application's and end- 
user's requirements for help, I sers should feel as if they 
haw never left Ihe application while getting help. 

During our initial prototyping of the current HP Help System, 
we kept stumbling on the same two key issues: performance 
(how to make the system light and fast j and packaging (how 
to make it easy to integrate into any OSF/Motif-based appli- 
cation and redistribute with dial application). Our initial 
help system suffered greatly in both of these areas, UP Vue- 
help 2.0 was server-based, large, slow, and dependent on the 
IIP VUE desktop. Any application using our help services 
had to run within the HP VI "E desktop environment 

We addressed these iwo issues with our curreni release and 
ended up with a very different package. To fix the perfor- 
mance problems of slow siariup times and heavy server- 
based implementation, we started copying hnu tionaUty from 
the help server into Ihe client via a linked-in help library. 
While prototyping this architecture, we quickly realized that 
we were duplicating Services. However, we were also get- 
ting much better performance from the new diem code. Ai 
that point w T e realized that if we moved everything to a help 
library we could fix our two biggest problems: performance' 
an. I packaging. 

By moving to a help library and removing our hard-wired 
dependencies on the IIP VTE desktop and by bundling our 
product with HP's User Environment Developer's Kit, we 
cleaned up our previous dependency problems with HP 
VUE, Now developers can embed help directly into their 
application and ship a single executable that includes both. 
Developers only have to link their OSF/Motif application 
with the HP Help System library and they are ready to go- 
All dependencies on external system and desktop services 
have been removed. Fig 2 si 10 ws an overview of OUT old and 
new r help system architectures. 

Following are some of t he advantages we gained by moving 

from our initial HP Vuehelp 2.0 sen -er-based implementation 

to an embedded client-side architecture. 
' Integration Advantages; 

OSF/Motif-based application program interface (simple to 

use lor developers familiar with OSF/Motif) 

I < unplete application control over the help system dialog 

management including creation, destruction, caching, and 

reuse 

- Smooth transition into the help system via consistent 
resource settings between the application and the help 
system (e.g.. same fonts and color scheme and quick 
response times) 



Embedded 
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Fig. 2. Two tJil'|fTf]ii approaches fco integrating online help into an 
application (a)Qieni sM« embedded fragmentation pngHPVUE 
&0 help; (b) Help server implementation usk\g HP VI E &0 help. Our 
initial t d that the clfeit s£& ett^eddedsaliiitotifi 

betler in terms of performance (rendering Lime) at id memory use. 

Immediate support for a tightly coupled app 1 1 cation- to- 
help system environment (e.g., application-defined and 
processed help controls such as hypertext links) 
Application -specific customization of the help system. 

• Packaging Advantages: 

Eliminates Installation and version problems (Since appli- 
cations are not si in ring the help services, the contention 
between older or newer software versions does not exist) 
Eliminates distribution problems. ("The help system is 
linked directly into the host application, tested and 
shipped as one executable.) 

• Performance Advantages' 

Requires less overall system resources (RAM and disk) for 
a single application using the help services 
■ Provides much faster initial response time when displaying 
help requests 

Integration Concepts, Practices, and Mechanisms 

As mentioned in the previous section, the run-time help 
facility is made up of a collection of help dialog widgets and 
files containing online help info mi at ion. The help widgets 
are linked directly into 1 he client application via the help 
library libXvKa* and instantiated by the client to display help 
information. While the help dialogs serve only as vehicles 
for displaying online help informal ion, standard OSF/Motif; 
Xlih, and X toolkit [ Xi ) services provide the glue to integrate 
the dialogs into the ap plica I ion. 

The online help files in the HP I hip System are called help 
volumes. These volumes contain the text for the help topics 
that are displayed in the dialog widgets. The following tiles, 
or volumes are used by the HP Help System: 

• volumeiiv. This is the master help volume file accessed by the 
HP Help System when a user makes a request for help infor- 
mation. It dun nation stored in This II le is used lo access the 
actual help topics stored In the help topic (ht) files. 

• volume.hvk, Tliis is a keyword index file for the master help 
volume, 

• volumeMN.ht These are the help topic files, where NN repre- 
sents file numbers (00, 01, 02 ., .). If there are no chapter 
elements in a help volume . only a single topic file (e.g., 
volumeOO.ht) will exist. These are the files containing the help 
text. 

The relationship between these files is shown in Fig. $. 
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Fig. 3. The HP help file system. 
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There are two levels of integration with respect to the HP 
Help System: integral irig help into an application and inte- 
grating a help-smart application into an IIP VI'E or IIP 
M Power desktop environmeni. 

Integrating Help into an OSF/Motif Application 

Developers have many degrees of freedom with respect to 
how much or how hide help capability they include in an 
application. If an application and its hc*lp information have 
very loose ties, then- may be only a handful of topics that 
I he application is able i<> display directly. In contrast, the 
application GOUld provide specific help for nearly every ob- 
ject and task fa the application. This requires more work, 
but it provides potentially greater benefits to the end user. 

Help Dialogs. r t\vo help widgets are supported in the help 
library: quick help dialog and general help dialog. They berth 
support Ibe same text, hypertext, and graphics display capa 
bilities, but differ with reaped to the remainder of the user 
interface. The quick help dialog (Fig. 4) is a very simple help 
dialog intended tor displaying small blocks of text to the 
user. Quick help dialog is best used for handling things like 
error messages, version Information, and object and item 
definitions. 

The general help dialog, which is the most commonly used 
help dialog, has a few more user interlace features than the 
quick help dialog widgel. Most notably, the Topic Hierarchy list 
(see Fig. I), which appears jusl above the help text display 
area, Indicates the location of the current topic- in I he help 
topic hierarchy. The general help dialog also provides vari- 
ous navigational aids to assist the user in moving abotil the 
online help information space 

Standard Xt Paradigm. The programmer interacts with the help 
dialogs in the same manner as any other OSF/Motif wii2: 
used by the application. The iwo types of help dialogs are 
defined by ibe following two widgci classes: 
* XvhQuickHelpDiafDgWjdgetClass (for quick-help dialog) 



■ XvhHelpDmlogWittgetClass (for general-help dialog 

Nearly every attribute of the help windows including the 
volume name and topic Identifier are manipulated as widget 
resources. For instance, to display a new topic, an XtSesValuesO 
call is made to set the volume, location identifier, and help 
type resources. 

Creating Help Entry Points 

Each help topic that can be displayed directly as the result 
of a help request is called an entry point That is. if thee 
at least one way to get directly from the application to a 
help topic, then that help topic is an entry point into help. 
Help menus and buttons in ibe application ait- the basic help 
entry points for an application. The types of help requests 
that provide entry points into the HP Help System are 
contextual help and item help. 

Contextual Help. Contextual help provides help Information 

about the item on which the selection cursor is positioned 
Contextual help information pro\ides users with information 
about a specific item as it is currently used. The information 
provided is specific to the meaning of the item in its current 
M,ih-. For example, suppose a user is running an application 
that uses an options widget I ha! has four options. If the user 
requests information on the widget while it has option 1 
selected, the user will get help information on the option 
widget in the context at its option 1 setting, 

A selection cursor, winch is a visual cue, enables users u i 
indicate wiib the keyboard the choice with which they want 
to interact h is typically represented by highlighting the 
choice wiili an outline box. 

The OSF/Motif user interface toolkit, through its help rail 
back mechanism, provides direei support foi contextual help 
entry points. When a valid help callback is added to a wid- 
tfet, and the user presses the help key (Fl ) while that vs idget 
has the current keyboard focus (e.g., selection cursor), the 
widget's help callback is autuiuatii -ally executed 

From within the help callback, the application bus ihe Op 
port unity to display some help topic based on the selected 



Help On Help 



Using the HP Help System 

We/come to the HP Hefp System. To learn about using help 
windows, choose one of the following hyperl-- 

• U j.'ig Kperlr- 

• Browjir-q Help. Topic? 

• Using tie Keyword In pes 

• Printing Help Topics 

• Revisiting Topics (He--. 

To choose a hyperlink: 

Any underlined text you see within a help window is a 
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widget, or the application could dynamically const nn i m m l< 
help information based on the current context of the selected 
iteni. 1 - 

Any level of granularity can he applied when adding help 
callbacks to an application's user interface components. 
They can he added to all the widgets and gadgets within the 
application dialogs, the top-level windows for each of the 
dialogs, or any combination in between. 

If I he user selects F1 help with the selection cursor over a 
widget or gadget that has no help callback attached to it, the 
OSF/Motif help callback mechanism has a fallback nvecha- 
nism for providing more general help. The help callback 
mechanism will jump to the nearest, ancestor that has a help 
callback assignee! and invoke that callback. The theory is that 
if there is no specific help on that widget or gadget, then it is 
better to provide more general help than none at all. Appli- 
cation developers art 1 responsible for adding their own help 
callbacks to the user interface components in their applica- 
tion. OSF/Motif sets these callbacks to NULL by default. 

Item Help. Item help allows users to get help on a particular 
control (e.g., button, menu, nr window) by selecting the item 
with the pointer item help uih n -iwiv ion should describe the 
purpose of the item for which help is requested and should 
tell users how to interact widi that item. An item help re- 
quest does not provide context sensitive information like the 
Current state of the selected item. 

Item help is usually accessed via an application's Help menu 
under the On Item menu selection. Once selected, the cursor 
is replaced with a question mark cursor The user can then 
select, the item of interest. 

The HP Help System API utility function, XvhRetumSelected- 
WidgetldO assists developers in providing item help within their 
application. Tins function provides an interface for selection 
of a component within an application. XvhRetLimSetectBdWjdgm- 
IdO returns the widget Identifier for any widget in the user 
interface thai the user has selected via the pointer. 

At any point while the question mark cursor is displayed the 
user can select the escape key (ESC) to abort the Htnction call. 
If the user selects any item outside the current application 
windows the proper error value will be rel tuned. 

Once XvhRetumSetectedWidgetldO returns the selected widget 
identifier, the application can invoke the help callback on 
the identified widget or gadget to process the selected item 
From the help callback the application can display some help 
topic based on the selected widget or dynamically const ruci 
some help information based on the current selected item. 

Integrating a Help -Smart Application 

There are no rest ricl ions regarding where nuvtime help fdes 
are installed. However, a suggested practice is to [jack age a 
help volume in a separately installable file set so that I he 
system adminismuor can place them on a system file server 
This will save local resources and make the help information 
available to a larger number of users. The default configura- 
tion is for the run-time files to be installed with the rest of 
the applications fdes. 

Another important step in installing help files is registration 
(or symbolic links to help volumes). The registration process 



JUNG —v 
V user/vhe Ip/vol umes/C/" 

HPHelpKilhv Vueititro hv 

Help4Help.hv Vueloym Jiv 

Sft&redXhv Vuttrtischv 



(a) 

SLANG — . 
/ii&er/vhelp/lafnrlies/Cr 



Vuewm hv 
browser hv 

iax.hw 



tipujtenor.hv reheat hv 

lipLlrnrilh I IV -,.jl1l|irilirt:r hv 

hpuxrttply.flv s ingle user, hv 



HPVUl III 



lb) 



SharrjdXhf 



M\ ire board. M 



Fig. 5, H«3p directory contents C*0 A portion of a directory runt&in- 
i r i g help v r, > I ui ties H ' i A 1 1 j n se! < ) rv containing p roduci families, 

enables two important features of the HP Help System: 
cross volume hyperlinks and prod net family browsing. 

Registering a Help Volume. After the run-time files have been 
installed, a help volume is registered by creating an HP-UX* 
symbolic link to the help volumes volumehv file. The link is 
created in one of the directories that the help system 
searches for help volumes (Fig, 5a). For most help volumes. 
I hr appropriate place for the link is in the /usr/vhelp/volumes/ 
SLANG/ directory, where SLANG represents the language of the 
help volume being registered. The default language for help 
files is usually English. 

Registering a Product Family. A product family is a group of 
help volumes belonging to a particular product. To register a 
product family, a help family file (product.hf) must be created 
with the rest of the product's help files. The family file is 
registered by creating a symbolic link to the product- name. hf 
file. For most products, the appropriate place for the link is 
in the /usr/vMp/families/SLANB/ directory (see Fig, 5b), 

Family files can be read with the helpgen program (part of 
HP VUE), which creates a special help volume that lists the 
families and the volumes within each family installed on the 
system, 

Access to Help Volumes 

The HP Help System has a simple, yet extensible mechanism 
for transparent access to help volumes installed on the desk- 
top. It supports both local and remote access to help vol- 
umes and works with any number of workstations. The only 
dependencies required are I he proper help registration as 
discussed above, NFS services (i.e., remote systems mounted 
to the local server), and proper configuration of the help 
environment variables discussed below. 

When an application creates an instance of a help widget the 
XmNhelp Volume resource can be set using either a complete 
path to the volume,hv file, or if the volume is registered, using 
the base name (Le,, the file name without the .hv attached ) i \t 
the volume. When using the base name, the help system 
searches several directories for the volume. The search ends 
when the first matching volumehv file is found. The value of 
the user's SLANG environment variable is also used to locate 
help in the proper language (if its available). 
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The environment variable XVHHELPUSERSEARCHPATH specifies 
the user search paih for locating help volumes. Whenever 
this resource is set to a relative path, the user's default home 
directory will be prepended to the value contained in the 
XmNhelpVolume resource. The de fait it value used when the 
environment variable is not set is: 

vtffiIp/%T/%L/%H.hv:\ 

vhelp/%T/%H h 

vhelftf%T/%L/%H:\ 

vhe!p/%H:\ 

vhelp/%T/C/%H.tiv:\ 

vhe!p/%T/C/%H: 

where: 

%L is the value of the SLANG environment variable 

(C is the default) 

%T is the type of file (volume or family) being searched for 

%H is the help volume specified. 

These path names are illustrated in Fig. 5. 

The environment variable XVHHELPSYSTEMSEARCHPATH specifies 
the system search path for locating help volumes. The default 
value used when this environment variable is not set pre- 
pends the string /usr to the strings given above. For example, 
vhelp/%T/%U%H.hv:\ becomes /usr/vheip/%T/%U%H.hvl Note that 
the user search path defined above takes precedence over 
the system search path, 

Run-Time Help Volumes 

The flexibility and power of this help system is largely 
placed in the author's hands. With the HP HelpTag markup 
language and a creative author, very different ami interest- 
ing approaches can be taken with respect to presenting in- 
formation to the end user. Documents can be organized in 
either a hierarchy with hyperlinks referencing the children 
at any given level, or in I he form of a network or web, with a 
linear collection of topics connected wilh hyperlinks to re- 
lated topics (see "Informal ion Models lor Online Help" on 
page 82 for nunc about these dociiiiien! organizations). It's 
up to die author lo explore I he many capabilities with re- 
sped to producing effective online help information for a 
particular system 

Help Volume Structure. A help volume is a colled ion of re- 
lated topics that form an online book Normally, the lopirs 
within a volume are arranged in a hierarchy Developers 
usually create one help volume per application. However, 
for complex applications or a collection of related applica- 
tions several help volumes might be developed. Topics 
within a help volume can be referenced by unique location 
identifiers that are assigned by the author. It. is through 
these location identifiers that help information is referenced 
in the run-time environment. 

Help Volume Authoring. ( >nlino help is written in ordinary texl 
Hies. Special codes, or tags, are used to mark up elements 
w it hin the information. The tags form a markup language 
called HP HelpTag. The HP I IcIpTag markup language defines 
a hierarchy of elements that define high-level constructs 
such as chapters, sections, and subsections, and lias level 
elements sueh as paragraphs, lists, and emphasized words 
(Pig. (i). The text files created by authors and any associated 
graphics files are compiled using the UP HelpTag software 
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<fitfe>Kelpdemo i Sample Application: 
■ccopyngtot- 

< graphic erttrtT=*eraJOflGraptne>.rtwm ooglasslHolpdemnl, Version 1 



Scopr C*ptfi|tat Hcwlfffi- Packard Companr t9H 
All Rights Reserved 



rt Thi* program b tm di aflMl fHiw puiporei Mitt? U 

obstrac&This online help volume it ifsefl wilti the helpdemo program 
that demortstrsies how to use the HP Help System in en OSrTMotif 
application 

tvnetsdrin? 

<hometopit>rlelpdernQ Kelp Information 
■odx l introduction 1 

Tins is the home lopic This is the top level ol voiit helpdemo 
help information 

Choose one ol the following links lo find ciri more about the helpdemo 
prog rent 

<f ist bulleb 

* **ref chapllDv 

* <xref chap21D> 

^chapter td=cbap1ID>An Application Help System 

■clistoulfeb 
1 <*ref onAppiicationMonu> 

* <xref sampleBtnOne> 

* <araf aampleBtnTwo> 
<^i«> 



<sl id-sflmpleBir>0ne>8urton One Kelp 

Here s the help lex! for oor sample button one- 

<s1 nl =sam pie BtnTwo> Button Two Help 

Here's the help text for our sample button two 

tsl id -onAp|iJicatiOiiMeuii.» Introducing Hclpdemo 

This is Ihe topic displayed by choosing On Application from ihe Help menu 

<c ha pier id-cttap2ID> Controlling The Application 

The 1 nil owing links demonstrate now the HP Help System can control the 
hosting application 

<{ ist bullet} 

* dink hyperlink- "100" type=AppDHmed> Move the window UP *-Jink * 

• -link hyperlinks "101" ivpe=AppDefined> Mnye the window DOWN *Muik> 

• '-link hyperlinks "102" type=AppUefift£d> Move the window LEFT tSlink> 

* .link hyperlink^ "103" typc^App Defined;- Move Ihe window BIGHT *-Mink> 

Note: The text cantarneri in the brackets "<>' is \hv tags that form the 
HP HelpTag markup language. 

Fig. ft* A Kiimplr HI 1 HelpTag volume r hat is distributed ;is pari of 
lheHPH'-j|- I >i -.■.■!:. ] :*-'■■: KjL. 

to create mn-tinie help Hks | Kig, 7). These run-time files (or 
volumes) are installed with the application and accessed 
when the user requests help. 

Help Volume Compilation. The HP HelpTag compilation pro- 
cess performs the following tasks in generating a compiled 
runtime help volume: 

* Syntax validation 

* Conversion fro in the authored formal to run-time format 

* Location identifier map generation 

* Topic coi upresstrm 

* Topic hierarchy map general ion. 
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While creating the help volume compilation process we de- 
veloped techniques for improving the performance (speed 
and size) of our system. Our objectives were to create a run- 
Time file format that supported very quick access (three sec- 
onds from request to display) for any requested help topic 
Contained within a help volume, while at the same time 
keeping the overall size of the volume as small as possible. 
Topics Willi graphics can sometimes be s!ow r er than three 
seconds. 

To solve the quick access problem, a scheme was devised 
that takes the physical luerarchy of authored topics within 
the volume and flattens the whole volume. During this pro- 
cess a jump table is generated that lists each topic name, the 
file that topic resides in, and the offset into the file that rep- 
resents the beginning of the topic. With this flattened format 
and the jump table, topics can be quickly retrieved for dis- 
play, The jump table is stored in the volume. hv file in X re- 
source format, and parsed using standard xrm function calls 
in Xlib. 

Help Volume Compression and Decompression. The size of 
compiled nm-time help files was a real problem in the first 
prototypes. The solution we developed to solve this problem 
involves compressing the topics in the help topic (*.ht) files. 
Tills task was added as the last step in the compilation 
phase of an authored help volume. 

The help data files are compressed on a per-topic basis. That 
is, each help file is read to determine the start and end points 
of each topic in the data file, This information is used to step 
through the data file T extracting each topic m turn, writing it 
out to a temporary file, and using the HP-OX utility compress! 1) 
to compress the file. Unless a special option ( -f ) is given to 
compress, the utility will not compress a II le if the file does 
not actually shrink. (The IIP Help System is able to read 
uncompressed files/) After executing the compress utility, 
the resulting file is checked for a 2 extension to determine 
if compression has actually taken place. 

If the topic is compressed, a null byte followed by fiuee bytes 
making up a 24-bit number holding the size of the topic in 
bytes is written to a new version of the help data file followed 
by the compressed topic. If the topic is not compressed, it is 
simply copied to the new r help data file. In either ease, a new 
version of the index file ( volume .hv file) is updated with the 
new starting offset of the topic based upon the size of t he 
previous topics. 



Since no uncompressed topic will ever start with a null byte, 
the leading null byte in compressed topics serves as a 
^magic number" to indicate to the run-time help viewer that 
the topic is compressed. The 24-bit size value written to the 
file in a fixed byte order allows help fUes to work on ma- 
chines with varying byte orders in machine words and is 
used by the decompression algorithm in the run-time help 
viewer to determine when in stop expanding a topic, 

After the entire help data file has been compressed, the new 
\ its ions of the help data file and index file are moved to 
replace the old versions. 

When the compression algorithm was first prototyped, w r e 
were pleasantly surprised by the results. The new scheme 
saved over 40% in disk use per volume while creating no 
end-us cr-visible performance degradation in rendering time. 
We use the standard HP-UX compress! T} command, which is 
called from the HP IlelpTag program to handle the compres- 
sion, and an embedded library version of uncompress for de- 
compression at display time. We determined that the lack of 
performance degradation in using compressed topics is 
partly because most of the help topics are very small and the 
embedded decompression function enables fast retrieval. 

Graphics Compression and Decompression. Support is also 
included for compressed graphics including X pixmaps, X 
bitmaps, and X window's, as well as JPEG compressed TIFF 
images, which are supported by the IIP Image Library, See 
the article on page 37 for more about the IIP Image Library. 
In most cases the best results, both for performance and disk 
use, are gained by using JPEG compressed TIFF images. 

Help Dialogs 

From the developer's perspective the help dialog is seen as a 
single widget. Widgets are created, managed, and destroyed 
as one single object. In reality our help widgets are not one 
monolithic help entity, but two separate very distinct com- 
ponents: the text display engine component and the widget 
component. The text display engine component as seen 
from the developers perspective is the region in the help 
widget that renders the text, and graphics, provides hyper- 
link access, and performs dynamic formatting of the text. 
The widget component consists of the OSF/Motif code that 
makes it a widget and the remainder of the user interface 
including topic luerarchy. menu bar. and supporting dialogs 
(print, keyword search, and history). 

The Help Widget. By building the help dialogs as true OSF/ 
Motif widgets (customized or pari of a toolkit) and exposing 
this as our help API, we immediately gained an industry- 
standard format for our help functions- The syntax and use 
model for programmers is the same for every OSFAToiif 
widget created. This makes it very easy for developers famil- 
iar witli OSF/Motif programming to understand and use the 
help widgets. 

The OSF/Motif-based API supports the various controls we 
need to manage an instance of our help dialog. Through 
standard OSF/Motif and X toolkit and Xlib functions, pro- 
grammers have direct access to the help dialog resources 
and can manipulate these values as they see fit, Developers 
can add callbacks via XtAddCallbacMI. set and modify re- 
sources via XtSetValuesO T manage and unmanage the dialogs 
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via XtManageChild and XtUnmanageChild, and free the resoui 
when done via XtDestroyWidgeiO. 

The Display Area, fed formatting on the display allows dif- 
ferent types of text The author can specify dynamic text 
that will format or reformat text according to the window 
Size The author can also specify static text that wil] not be 
reformatted to adjust to different window sizes. Fcm 
nannc text a sequence of two or more spaces will tie com- 
pressed into a single space and internal newlmes (Returns or 
Enters) will be changed into a space. K ext all spaces 

and internal newlines will he honored. 

Help system users demanded the ability tu resize help win- 
dows, While vertical scrolling is accepted as necessary 
when help topics are longer than the available screen spare, 
horizontal scrolling is not. Therefore, dynamic reformatting 
is a must, 

Foreign Language Format. Text formatting for foreign lan- 
guages placed some special demands on our display area 
text formatting widget 

European (8-bit) rules. For most European languages (includ- 
ing English), breaking a line of text at spaces is sufficient. 
The only other line-breaking rule applied is wilh hyphens. If 
a word begins or ends with a hyphen, the hyphen is consid- 
ered a part of the word. If the hyphen has a nonspace before 
and after it, it is considered a line breakable character and 
anything after it is considered safe to place on the next line. 
Asian (16-bit) rules. For Asian language support, breaking a 
line of text on a Space is unacceptable since some lG-bit lan- 
guages do not break their words with spaces (i.e., Japanese 
and Chinese, bul not Korean). With the Japanese language, 
ihe e haracn-rs are placed <>ne after another without any word 
breaking character because each character is considered a 
word. There is also the concept that certain characters can 
not be I he first character on a line or the last character on a 
line. English (8-bit ) characters can be mixed with IB-bit 
characters. 

Given these consi derations, The following line-breaking rules 
for 16-bit languages are used: 

1. Break on an 8-bit spare. 

2. Break on a hyphen if the character before and after the 
hyphen is not a space, 

3. Break on an 8-bit character if it is followed by a 16-bit 
character. 

4,Breakona it>bil character if it is followed by an Shit 
character, 

5. Break between two 16-bit characters if ihe tlrsi character 
can be the last character on a line and the other character 
can be the first character on a line 

Rather than hard code the values of those Japanese charac- 
ters that can't start or end a line into our help system, a 
message Catalog system tS used. This provides a general 
mechanism for any 16-bif language. All language localization 
support people are required to determine which characters 
in i heir language cannol start or end a line and localize the 
appropriate native language support t NLS) file. The file /osr/ 
lib/nls/%T/%L/fmt_thl.cat contains the values of those characi i us 
that are used for rule 5 of the line-breaking rules. If (his file 
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Fig* 8. Text flowing around a gcaj 

does not exist for a given language, rule 5 is ignored and line 
breaking will occur between any two 16-bit characters. 

Even using these line-breaking rules, sometimes the lines 
are still too long to fit in the available space. For this case or 
when static text pushes the boundary of the display area, 
the help system gives up and displays a scroll bar so that the 
user can see the information without having to resize the 
window. 

The help system uses the same routines for processing 
English or mnltibyte documents. These routines determine 
what line-breaking rules to use based on the SLANG environ- 
ment variable and the character set used in the document. 

If a document specifies an ISO- LATIN 1 character set, the 
display engine does not bother looking at rules 3 to 5 or using 
multibyte system routines. Only when the document and the 
SLANG environment variable specify a 16-bit character set are 
these rules and routines used. This minimally impacts the 

ESS and rendering time but allows the same binary 7 to be 
used in the United States, Europe, and Asia. 

Flowing Text. The help system display area also pn k ides die 
ability to How texi around a graphic, This is seen <is a space 
saving measure and a highly desired feature. The graphic can 
be placed On the left side or the right side of the display area 
and the ie\i occupies the space to the side of the graphic. If 
the texi is too long and does not fit completely in the space 
beside The graphic, the text wraps brims ihe graphic. Fig. 8 
shows an example of this graphics formatting technique. 

Graphic Manipulation, Complaints about the text only nature 
of HP Vuehelp 2.0 strongly demonstrate the truth of the 
adage "one picture is worth a thousand words," Therefore, 
the help system tries to allow as many standard graphic for- 
mats as possible. During the design of \h* % help system the 
question was, which ones to allow? Eventually, it was deter- 
mined to allow standard X graphics (nlus the new X pixmap) 
and TIFF image formats. The reason for selecting the X 
graphic formats is that they are supported by standard XI ib 
routines for accessing graphics filrs, and the reason for 
choosing TIFF format is that the HP Image library supports 
TIFF format. The formats supported by the help system 
include: 

• X bitmaps 

• X window files 

• X pixmap fill S 

• TIFF r wi. 

Graphic Compression. While JPEG compression schemes are 
Common for use with TIFF files, no compression was being 
used willi the X graphical formats, After numerous com- 
plaints from authors about how much space Xwd fdes 

(continued on page B8) 
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WYSIWYG Printing in an X Application 

The HP Help System provides several features that allow authors to specify different 
fonts in various sizes and combine them with graphics bitmap illustrations. These 
capabilities and others created special challenges when it came to WYSIWYG 
(what you see is what you get) printing The HP Help System developed some 
sophisticated techniques for handling WYSIWYG printing 

What Is WYSIWYG? 

Our market research uncovered a strong demand for WYSIWYG printing without a 
dear definition of what WYSIWYG really meant. One obvious interpretation is the 
screen dump that accurately represents an paper what is on the screen This is 
appropriate for some applications, but prototypes of this approach showed jagged 
characters crammed into a smell 4-by-6-inch window on a large SVz-by-t 1-inch 
piece of paper This satisfies no one. Another approach is to take a printed image 
and display it on the screen matching I me breaks as they appear on the printer 
This approach compromises readability on the screen, which is not acceptable for 
an application providing online information, Fig. 1 shows one interpretation of 
WYSIWYG printing. 

The interpretation of WYSIWYG we chose for our help system is based on the 
notion that ''WYSIWYG is a state of mind." True WYSIWYG is undesirable, but an 
appropriate illusion of WYSIWYG is the right answer for the HP Help System, we 
give presentation on the screen and presentation on the printer separate consider- 
ation The printed page uses the same fonts as the screen isans serif for the body 
or the text and serif fonts for titles I. hut printer fonts are laid out and rendered at 
300 dots per inch. The help topics are laid out to fit on the size of the printed page, 
and each page has page numbers. Thus, line breaks and page breaks on paper do 
not match line breaks and screenful on the display, but this is just what our cus- 
tomers are looking for. Fig. 2 shows a comparison of screen and printer output. 

Font Availability 

We took care to allow the HP Help System to work with any X server. This was 
important to us, since we knew our work was likely to be ported to other platforms 
besides the HP-UX operating system. What is more, the distributed nature of X 
means that even though the application may run on an HP-UX computer, it can be 
displayed on a totally different device, such as an HP Vectra PC running an X 
server under Microsoft' ' Windows. It is difficult to predict what fonts might be 
available to the server 

To enable the help system to use fonts available on any display server as well as 
those built intD HP LaserJet printers, we developed a table that maps generic help 
fonts to specific fonts available on the target server or printer. After having studied a 
variety of HP documentation, we identified a need for three font families for help 
messages: a serif proportionally spaced family (like Times), a sans serif proportion- 
ally spaced family (like Helvetica), and a serif monospace family (like Courier). 
Each family contains four treatments normal, bold, italic, and bold italic. Table I 
shows these fonts, For special characters, a symbol font is also included Our 
discovery of this was no surprise It corresponds very closely to the 13 typefaces 
typically found in PostScript™ printers and in the HP LaserJet Hi prmter. 



This is a screen display that uses printer metrics. 

H will look really great printed out, but on the screen, 
the character spacing is very uneven, Hiis is especially 
evident when the same character is repeated as in the 
rows of characters below. Notice also how some letter 

combinations are uncomfortably crowded together^ 

mm mm mmm mm mm mmm 







Table 1 








HP Help System Generic 


Fonts 




Typeface 




Treatments 




Category 












Normal 


Bold 


Italic 


Bold italic 


Serif 


A 


A 


A 


A 


Sans Serif 


* 


1 


-- 


A 


Monosp-. 


A 


A 


A 


A 



For screen use, we mapped our generic fonts to fonts included in the standard X 
distribution, which is available on most if not all X servers. The distribution uses 
(Slew Century School hook, Helvetica, and Courier fonts. Should these fonts not be 
available, an administrator can change the mapping table. The table is in an X 
resource file For situations in which all the fonts are not available, several generic 
fonts can be mapped to the same physical font. We did rrns with Asian languages 
in which all four typeface treatments are not available. For Japanese, the serif 
family is Mincho and the sans serif family is Gothic, but all treatments are mapped 
to the one treatment available. 

For HP LaserJet 111 printers, we used the same scheme to ensure we used the 
built-in fonts CG Times, Univers, and CG Courier. Thus, the fonts on the printer are 
not identical to those on the screen, but they are close enough to create a 
WYSIWYG state of mind to our users. Table II shows various font family mappings. 

As an example of how this mapping works consider an application that requests a 
sans serif bold IZ-point font This request will be honored with Helvetica on a 
European X server, Univers on an HP LaserJet III printer, and Gothic on a Japanese 
X server. 





Table II 
Font Family Mappings to Printer or Screen 






Fonts Available 




Typeface 
Category 


X Server 

(European) 


HP LaserJet HI 


X Server 

(Japanese) 


Serif 


New Century 
Schoolbook 


CG Times 


Mincho 


Sans Serif 


Helvetica 


Univers 


Gothic 


Monospace 


Courier 


Courier 


Mincho 



Fig. 1. One interpolation of WYSIWYG printing. 



Use of generic fonts worked so well for us that we are now investigating ways to 
build this capability into X font servers so that applications can be assured of a 
reasonably rich set of fonts no matter what the platform or the current locale. 

Xlib for Printing 

The traditional approach to the implementation of printing in an application is to 
write the rendering code at a reasonably high level and then write specific drivers 
that convert from the higher-level code to the page-description language of the 
primer With this approach an application might end up with a large number of 
drivers, one for each specific type of printer 

We addressed printing rather late in the development cycle By the time we began 
developing printing support, the rendering code had already been written directly 
lo XI ib # making it difficult to develop a higher- 1 eve I tool kit as described ahuve, We 
turned this vice into a virtue by experimenting with a new concept using XI lb 
functions. 

Using some X toolkit and X motif routines we developed a clone of Xlib called 
Xvplih, which has the same functions as Xlib, but generates PCL instead of X 
protocol. Printing is done through a separate program called help print which is 
called by the help widget The heipprim program uses the same help library [Xvh] 
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Fig. Z A comparison between display lleft] and printer Inghtf output from the hefp system 

as the display program but links with XvpLib instead of XI ib for the printer driver 

code (see Fip M 

The heipprim application uses the Xlib call XOpenDtspfayO to open a printer and 
then uses The XCreateSim pleWindowf) routine to create a window on the print 
display This window reflects the margins on the page. Tbe help-rendering library 
UvhJ (hen renders the current help topic into the wrndow. Ihe rendering process 
performed by Xvh involves retrieving the window size using XGetWindowAttributest), 
loading fonts using XLeadQueryFont, and using XDrawlmageStringO to render text 
until done The Xvjilib library provides the XI ib functions and generates the PCL code 
required Many pixel arguments such as width, height x, and y are much larger to 
printer displays than to screen displays because of Ihe 300-dpj resolulion of the 
printer. However, calls such as XT&atWidthO, which returns the space required to 



Display Program 



Print Program 



X Application Program interface 



X Protocol PCL 



Xvh ■ Help Library. 

Xhh - X Library. 

Xvjilih = Printing Library. 

Fig, 3. The architecture far HP help printm-i ijriyett toi the disjrieyand for the printer. 
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draw a string, still work fine The XvpUh library supports both the HP LaserJet II 
IPCL 4| and the HP LaserJet III (PCL 5| printers. The prrmary difference between 
them is the selection o! built-in fonts The match from X to PCL was surprisingly 
close, but some X calls (such as XORmq bitmaps) had to be interpreted liberally. 
XvpLib supports all 36 X functions used by the help topic fibrary Xvh 

Using X as our print interface worked very well Only about three lines of code had 

to be added to the help-rendering library fXvhl to support printing Common render- 
ing code for the screen and printer made it easy for us to keep the layout of help 
topics consistent between screen and printer 

Printing for Special Printers 

The printing approach described above works very well with PCL poolers However, 
HP customers in Japan presented us with special challenges. First, the Japanese 
language requires support for 1 6-bit text, and these customers typically have 
printers that support Asian page description languages such as Canon's UPS and 
Ricoh's RPL 

To support such requirements, we took a different approach Instead of using 
heipprim to render to the printer, we developed another rendering program called 
helpprintrst This program creates an offscreen pixmap the size of a sheet of paper 
on the X server and and then calls Xvh to render into that piamap. The print pro- 
gram retrieves the completed page using XGetlmageO and sends it tn the printing 
library [XvpLib) to turn the image into a PCL bitmap Special filters in the print 
spooler convert the PCL bitmap into a bitmap suitable for the target printer, 

Axel Deininger 
Fngineer/Screntist 

Workstation Technology Division 

Microsoft tsa U.S. registered trademark of Microsoft Corporation. 

rfpl is a trademark o! Adobe Systems Incorporated which may h& registered m certain 
iurisdtetions 
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require, the help system was modified to find and access 
compressed files. The author uses the same HP-UX com- 
pression utility mentioned earlier to compress the graphic 
files. The same internal decompression routine used to de- 
compress topic files is used to decompress the graphic tiles 
inm a temporary file. After decompression, the help system 
reads the graphic file as usual. 

I "sing compression on X graphic files can impact access 
time. For very large graphic images or for a topic that uses 
many graphics, this impact can be noticeable. The Irade-off 
between speed mid disk space is one that the author and 
application engineer must address. 

Color Degradation. Another obstacle encountered with han- 
dling graphics was color graphics on grayscale or black and 
white displays. Having to provide three different images for 
the three types of displays is not feasible because ot disk 
use. Therefore, the help system has to degrade a color linage 
for grayscale or black and white displays. 

For X bitmaps, this is no problem since bitmaps are specified 
as using t he foreground and background colors only. For 
TTFF images, the IIP Image Library forces the image to the 
proper color set depending on t he display type. For X pix- 
niaps, the Xlib routines take the same approach depending 
on the display. Tins leaves tire X window files to manipulate. 

The task is to reduce an Xwd file from a full color image to a 
grayscale image containing no more than the maximum 
number of gray colors we have available. 11 lis number is kept 
in a variable called MAX_GRAY_CQLORS. The HP Help System 
uses eight gray colors. The first step in this process is to map 
each of the X window color pixels to a grayscale luminosity 
value f(B in Fig. 9). This is done using the NTSC (National 
Television Standards Committee) formula for converting 
RGB values into a corresponding grayscale value: 

luminosity = 0.299 x red + 0.587 x green + 0.114 x blue 

where red. green, blue are the X window color values in the 
range of to 255. This creates a grayscale luminosity value 
in the nuige from to 2">5, 

The next step is to determine the number of distinct lumi- 
nosity values used in the image. This involves counting the 
total number of luminosity values computed above ( - in 
Fig. 9). The idea is to group the grayscale luminosity values 
across the available gray colors so that the image can be 
evenly and reasonably rendered. 



After determining the actual number of distinct, luminosity 
values used in the image, a further calculation is done to 
determine which gray color to use for a given group of lumi- 
nosity values (<D in Fig. U) t If the number of distinct lumi- 
nosity values is greater than or equal lo MAX_GRAV_C0LORS. 
then each gray color will he used at least once. However, if 
the number of distinct luminosity values is less than 
MAX_GRAY_COLQRS a calculation is performed to spread the 
color load among the gray colors instead of bunching them 
together. This provides the contrast in an image. 

Filially, when the image is rendered To the display the shade 
of gray associated with a particular group of Luminosity val- 
ues is mapped to the appropriate display pixel (\ in Fig. 9). 

If the system has to degrade the image to black and white, ii 
first calculates the grayscale colors using the luminosity cal- 
culation described above. Then it dithers the image using a 
Floyd-Steinberg error-diffusion algorithm, which incorporates 
a Stucki error fitter.'* 

The end user can force the whole environment including the 
help system to use grayscale or black and white by setting it 
via the HP VIE style manager's Color Use dialog. Also, it an 
image uses more colors than are available in ihe color map, 
the help system will automatically degrade the image until it 
is renderable. 

Hard-Copy Support 

A critical and difficult requirement of this help system was 
to provide WYSIWYG (what you see is what, you gel) print- 
ing support, to match our text display capabilities. To ensure 
good performance and not tie up an application just to print 
out its online help, we implemented the printing mechanism 
as a separate application. When an end user requests to print 
one or more topics in the current help volume, the widget 
code packages the request and performs a vfork(2) to launch 
the print application. 

The help system supports I wo different print applications: 
helpprint which is for HP LaserJet printers (i.e., PCL support ) 
and hefpprintrst for printing help volumes that contain multi- 
byte characters such as those used in some Asian languages. 
The helpprintrst command operates just like the helpprint com- 
mand except that its output does not depend on printer 
fonts Instead, helpprintrst creates a page-size graphic image 
of each help topic. 
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Fig, 9. The process of re during 
u r i j 1 1 CjOlor image to a grayscale 
image. 
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Fig. 10. \ localized help wirwioTV- 

The goal in implementing a WYSIWYG printing solution for 
i he help widgets was centered on creating a solution that 
COtild solve fhe printing problem for many applications, not 
just i he MP Help System Refer to "WYSIWYG Printing in an 
X Applieai u m," on page 86 for a description of Ihe printing 
solution used by the IIP Help System. 

LocalizaoiJity 

The HP Help System supports the authoring and displaying 
of online help in virtually any language. The online help in- 
formation can be authored and translated in either single- 
by ir or inuHihyte character sets. All the components wiihin 
the develop* rs kit are muliibvte smart and can parse and 
display the localized information. 

The help widgets use Ihe SLANG environment variable to de- 
1 ermine which language directory to search to retrieve the 
requested help volume. For example, it SLANG - Japanese 
when I lu i request to display help occurs, the widget codfi 
will attempt to open Ihe -Japanese localized version oTthiil 
help volume. If one does not exist, then the default version, 
which is English, will he used 

When an authored help volume is compiled via HP HelpTag, 
the author sets the proper character set option. The character 
set Information is used at run time to determine the proper 
fonts to use for displaying the localized help text. The default 
character set for the HP HelpTag compiler Ls the one definci I 
for 8-bit character sets by ISO 8859- L Currently only one 
character set per volume is supported. 

Km U) shows a Sample of a localized help window. 

Parsing Multibyte Characters. To make a single tool work for 
single-by I c and mull ihyte character sets without constantly 



checking for the length of the current character, all charac- 
ters are converted to wide characters on input. This input 
conversion is driven by either command hue option, on an 
IIP HelpTag entity file, or by the current setting of the locale. 
All internal processing of characters is done an wide charac- 
ters with those wide characters being converted back to 
multibyte characters on output Single-byte chara* 

+ j ated just like nn j iracter sets in that the 

same input and output conversions always take pi.: 

This scheme of doing all internal processing on wide charac- 
ters has proven to be a very effective means for making one 
lool work for all languages. The scheme did require imple- 
mentation of wide character versions of most of tl i 
functions (e.g., strcpy, strlen) but those functions were all 
quite straightforward to create. 

Localizing User Interface Components. The menus, buttons, 
labels, and error n liar appear in help dialogs also 

support full loraJi/aiiuh i< ■ native languages. The help dialogs 
read the user interface component strings from a message 
catalog named Xvh.cat Different localized versions are sup- 
ported by default and included with the developer's kit. For 
languages not supplied with the help system, the developer 
must translate the message catalog /usr/uhelp/nls/C/Xvh.msg and 
then use the gen cat command to create the needed run-time 
message catalog file. 

Ackno w ledgme nts 

The authors wish to acknowledge all those who contributed 
to the design and development of the IIP Help Developers 
Kit, including the R&D, learning products, and marketing 
groups at the Open Systems Software Division in CorvallLs, as 
well as the many other contributors throughout IIP Appred 
ation to Brian Gripe for his willingness to beat the issues 
into resolutions, to Axel Deininger for performing ending 
jiiuaeies with respect to wysiwy< ! printing, and n> the many 
managers that supported this project through to release: 
Roll Miller, lock McKay, and Ken Bronstein. Special thanks 

i^oes to Pes Si 1 1 id i foj helping oui team understand the 
value of SGML and pushing us in thai direction with respect 
to our product ottering 

References 

] t >sr xinnj S5^fe Quid* , Revision l .2, Prentice-Hall 

2. OSF/Mo m r Programmers OuuirAU '\i si< m .1,11 Yen tice-Hai 1 , 1 ! v - J 1 

a K. Hiohnoy. Digital Soffltming, MIT Press, 1988, pp. 2:^-244. 

:■ .i .if is a ttffidemarfc of Ihe Opei* Software foundation in ihe U S and other countries 

UNIX is a registered trariBmaik of UNIX System LafxSBtories Inc. m she USA and oilier countries. 

HP-UK is base; pa&to wrtti UNW System Laboratofiea' UNIX operating system 

It also complies with >.. POSIX 1 D03 1 and SVIDZ interface specifications. 

X/Qpeii is a Tractemart of X/Open Company Limited in the UK and other countries 



)Copr. 1949-1998 Hewlett-Packard Co. 



April I'll I li'wlet i -Packard Journal 89 



Developing Online Application Help 

The primary goal for an application help system is to provide the capability 
for the end user to get useful help information and get back on task as 
quickly and successfully as possible. 

by Dex Smith 



Nearly 2000 online help topics are shipped with the HP 
MPower product. Throughout the HP WE 3.U and HP MPower 
projects, we've learned a lot about online help and its role 
with application software. 

This paper describes online help and rovers many of the 
issues encountered by application developers and authors. 
First, we out line the purpose of online help and suggest a 
use model Second, two common information models are 
described. Including how each relates to the domain of online 
help. Next, we discuss what is perhaps the most challenging 
and controversial topic in online information—navigation. 
Although this paper won't go into the details of these debates, 
it does reference some of the concerns and issues. Finally, 
we examine the roles of developers in a typical project, and 
we look at how these roles and online help systems may 
change in the future. 

Although much of this material was developed flu ring the 
design of the HP Help System and includes examples from 
that product, most concepts and ideas can be applied to any 
help system. The details ol 'the Implementation of the HP 
Help System are described in the article on page 79. 

The Role of Application Help 

To understand the purpose of online help, we begin with a 

prioritized list of goals, called a goal hierarchy. 1 Our goal 

hierarchy for online application help consists of the 

following: 

1. The user leaves the help system. 

2. The user is satisfied with the help information. 

3. The application s response to the user's request for help is 
appropriate. 

4. The help information is appropriate, even if the system 
response is not. 

5. The user can pursue additional information. 

From the user's perspective, the first Two i*oa!s are clearly 
most important The user wants to get out of the help system 
and back to work. Obviously, we want the user to return to 
work with useful information. 

To application developers, goal 3 is an important reminder 
that help is part of the application. A well-designed applica- 
tion will use everything at its disposal (current modes, recent 
user actions and errors, and other contexts } to determine 
the best possible response to a user's request for help. 



Goal 3 is also important to designers of a help system. It 
emphasizes that the design must provide the flexibility and 
power for application developers to integrate online help 
lhal is capable of responding as the user expects. 

The fourth goal represents the help author's obligation to 
design and deliver the most appropriate information. It fur- 
ther acknowledges that there may be limitations in the help 
system, or in the application's use of system features, that 
the author may need to work around in designing Ihe online 
information. 

Finally, with the fifth goal, if the user's need is not immedi- 
ately met, the system must allow the user to seek additional 
information. 

All of these goals can be summarized in a single prune direc- 
tive for an application help system — get the user back on task 
as quickly and successfully as possible. 

The Application Help Use Model 

Since the overriding principle for providing online help is to 
get the user back on task, online help must be easily accessi- 
ble within whatever applications the user has chosen to ac- 
complish the task. To that end, o nl me help is cast in a sup- 
porting role. That is, the help system's job is to function as 
pad ol the application with the purpose of making the user 
successful willi the rest of the application. 

Keeping the help system tightly coupled with the application 
improves the user's perceived proximity (Le., keeping the 
user feeling close to the application). If deviations to get 
help don't take users far from their current context within 
the application, they are more likely to stay on task and be 
productive. Avoiding unnecessary context switches is a 
fundamental human factors guideline. 

The software architecture used lo implement the help sys- 
tem doesn'1 necessarily have to be part of the application 
The HP Help System's toolkit allows software developers to 
embed the help system within the application or to create a 
standalone help server, 

If the help server model is used, special attention must be 
given to window manipulation and user interface design, so 
( ha i the user still perceives the help as part of the applicai ion. 

Handling Help Requests 

hi its simples! form, file interaction of a help system is a 
request/response transaction model. A request is made that 
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represents a need for information, and the system responds 
n niding information that meets the need 

For IIP Help, we have categorized help information retrievals 
using the terms automatic , semiautomatic, and manual as 
follows: 

• Automatic help The application determines what help to 
present and when to present it For example, an wror mes- 
sage is automatic help because Die application automatically 
provides informauon to the usa sometimes called 
system-initiated help. ) 

• Semiautomatic help. The application determines what help 
to present based on the current context in the application. 
The user determines when information is presented by mak- 
ing a request for help. The de facto standard gesture for ihis 
kind of request is pressing the Fl key. 

* Manual help. The user requests a particular type of help. In 
this case, the user determines what kind of help and when to 
<li liver it. Most manual help requests are made by choosing 
a help command from the application's Help menu. 

Entry Points into Help 

When a help request is made (either hy the user or automati- 
cally by the application), the system responds by displaying 
a help topic. Each topic that can be displayed directly as the 
result of a help request is called an entry point. That is, if 
there is at least one way to get directly from the application 
to a help topic, then that help took is an entry point into help. 

Any single topic may be an entry point from more than one 
context within the application. The redundancy of overload- 
ing entry points in this way can often be advantageous to 
the user* 2 For example, a topic on entering numeric data 
may be appropriate help for many places within a database 
application. 

Styles of Entry Points. < hirgoal hierarchy and use model Ills 
led us io classify two styles of entry points for help topics: 

* Quick help. This style present* a focused fcOpiC for I he enr- 
renl context, intended to meet the users need and then to 
be immediately dismissed, 

♦ < ■ moral help. This M\ l< presents a help topic for I he given 
request with the understanding I hat the user is likely to 
want additional information. 

Comparing the two styles is like contrasting an information 
booth with a consulting office. At an information booth, 
contexts are wen-defined, questions are generally short, and 
answers come quickly enough Thai there's no need n>sit 
down. In seeking the services osl s consultant, however, flu* 
expectations are different Yim want to make good use of 
your time to leant, see examples, ami explore related 
subjects SO you don't have to come hack, 

An entry point into help is the first thing a user sees when a 
help request is made. The presentation, user interface, and 
information content set ihe user's expectations about how 
specific the informal ion is lo tin* current context and how 
quickly il can be dismissed. 

For most applications of even moderate complexity, a com- 
bination of both styles of entry points is appropriate. I 
next two sections describe each style in more detail. 

Topics thai are not entry points can be reached only by 
navigating from other topics or by other means within the 



Help 



Print Report 

Prints the current report to the default printer The 
format of the rep: notions in the Options 

menu and in the Print dialog box 

To cancel a print job, choose Cancel in the Print 
dialog box 

See Also 

• Choosing a Printer 



OK 



Backtrack 



Browse , 



Print 



Fig. 1. A sample quick help dialog from the HP Help Sysn 

help system. Therefore, the organization and relationships 
between help topics are important to designing appropriate 
entry ] joints. The impact of ihe organization of help topics 
on navigation is discussed later. 

Quick Help. Quick help entry points are optimized by writing 
style, presentation, and user interface to get the user back 
on Xask with minimal interruption. Quick help should have a 
very simple user interface and present easily consumable 
portions of information. 

The quick help concept addresses the first goal in our goal 
hierarchy; User leaves the system. The second goal — User is 
satisfied with the help information — is up to Ete designers. 
That is, the correct entry point must be displayed and it 
must contain correct and useful information. 

Quick in If topics lypif ally have a high level of context sen- 
sitivity and contain very Specific information. By design, the 
content and presentation of ijuick help should no! encour- 
age tii* 1 user to explore. Hypertext links ( hyperlinks ) should 
be used sparingly, and restricted to closely related topics 

Notice the Browse. . ballon in Fig. I. This is an example of 
bow goal 6 m urn goal hierarchy ran be addressed for <|iiick 
help. Thai is. ihe Browse.., button provides a path for die 
user to seek additional information. 

Quick help entry points are recommended for automatic and 
Semiautomatic help requests. Some manual help request *- 
may also use quick help, depending on whai lype of informa- 
tion is being requested. For instance, users expect minimal 
interruption when requesting "help on version* 1 to get copy- 
right and version information. 

Typical uses <>r quick help Include Hie following: 

* Em>i messages, progress information, and feedback on 
user actions 

* Context-sensitive help (invoked with the F1 key or Help button 
in ;i dialog) 

rt help (help on a particular item orarea on the display) 

* Application copyrighl and version 

* Simple help on help. 
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General Help. General help typically covers the remaining 
entry points into online help- General help may have a more 
feature-rich interface for searching and browsing, Typical 
uses of genera] help include: 

• Application overview 

• A follow-up to quick help when quick help isn't enough 
(This use may follow one 1 or more steps in a progressive 
disclosure sequence (described below).) 

• Tutorials (Some tutorials may want to be more restrictive 
on navigation and prefer to use the quick help model.) 

• Online documentation f For browsing online information 
written and organized like a traditional manual) 

A sample general help dialog is shown in Fig. 2. 

Progressive Disclosure 

Even I he best online help implementations are unlikely I o 
provide entry points into help topics r hat. meet every users 
need for each possible situation. 

So, what if a quick help entry point doesn't fill the user's 
need? Progressive disclosure sequences are designed to 
maintain a sense of proximity, while exploring a constrained 
path of topics that incrementally provide more information 
for the given context. (This concept is sometimes called 
progressive revelation or progressively more help.) 

Often, a progressive disclosure sequence leads the user 
from initial "how in" context sensitive help through topics 
that are more motivational ("why 1 ') and eventually to de- 
tailed reference information Generally these sequences use 
a simple quick help interface for the llrsf two or three pro- 
gressions. At the point in the progression when the subject 
matter will likely lead the user to want 10 browse, the inter- 
face should provide additional browsing capability. 

Fig. 3 shows how a quick-help dialog can provide a More 
button for walking through a progressive disclosure se- 
quence. In each step in the sequence the dialog is reused, 



Welcome to HP VUE 



Fite Search Navigate 



Help 



lapic Hierarchy 



Welcome tn HP VUE 
What's New wish Version 3.0 



Toolboxes for Managing Applications 

TooKioxeii a:E containers fcr appti canons, a toons, and 
other accessaries. Here's a description of the Ssofeexas 
available from the HP VUE F r onT Panel: 

ou' Personal Toolbox is (or applications and 
accessories you user ggularly. 



Shows Depth 

and Location 

Within [he Help 

Volume 



The General Toolbox provides access to 
applications and accessories installed on youi 
system 

Thj Nehtfprfc Toalbort provfdes access to 
applications and accessories stared on c f he> 
systems on the nctwort. 

£| Marketplace is a plana to Ida* for infor-nation 

y. ' ^ about application software or other products 
available for y&a wtiH station. 



ss 



NOTE 

Toolboxes are not available in HP VUE Ltte Instead 
Ehe Tods suopanei contain a few common applications. 



Hyperlinks for 
Navigation to 
Other Topics 



until the last, step when the More button is renamed Browse 
and leads to a general help dialog. 

Information Models for Online Help 

In designing online help for an application, it is important to 
i irganize the informal ion in a way that best fits the applica- 
tion. A tight coupling between lhe application and its help 
Information typically makes the informal ion more useful 
when it is needed 

The help topics associated with an application are collec- 
tively called a help volume. Essentially, a help volume is like 
a book or document for the application. (However, we avoid 
the terms "book" and "document" because they tend to skew 
expectations. Further, some help volumes may have very 
little in common with their paper counterparts, such as a 
table of contents, chapters, and so oii.i 

Typicalh I here s a single help volume for each appHcatiGtt 
For very complex applications, or applications with distinct 
user groups, multiple volumes may be appropriate (Pig. 4). 

Standalone Help Volumes. Nni aU online help is directly associ- 
ated with an application. Help for the operai ing sysiem t for 
example, isn't associated with any single command, program, 
or utility. Therefore, the information models for online help 
must allow for standalone help volumes. 

Since standalone help volumes are not associated with an 
application, there must he a way to access 1 hem. One 
method is to provide a help manager. A help manager is 
simply an application that treats one or more volumes as its 
own and provides navigation into each volume. A help man- 
ager may provide entry points into help volumes that are 
also accessible from applications as shown in Fig. 5. 

Implicit Relationships. Within a help volume, there are two 
significant organizational models: hierarchical and n on hier- 
archical* Most technical information is organized hierarchi- 
cally like a traditional manual, in which chapters contain 
sections, sections contain subsections, and so on. Relation- 
ships bet~ween nodes of informal ion are created implicitly 
based on the hierarchy created by the author Fig, 6a shows 
a typical topic hierarchy, 

Hierarchical navigation tends to give users more confidence 
in knowing where they are. There is a sense of depth (num- 
ber of levels from the top] and movement (up, down, lateral). 
Hypertext links can be added to connect nonadjacent, but 
related topics (Fig. Ob). In this case, hypertext is perceived 
as a bonus, because it provides jumps that span the hierar- 
chical st run ure. 

Explicit Relationships. The free-form nature of a nonhierarch- 
ic a I information web allows authors to organize their infor- 
mation into hierarchies, circles, trails, webs, and grids. Fig. 
6c shows an information web. Relali< utships are created 
explicitly with hyperlinks. (In some systems, end users can 
create their own links to connect related topics.) 

When navigation is based entirely on hypertext, authors 
have much more flexibility to create any type of structure* 
This level of freedom requires a higher level of skill on the 
authors part. Links to and from each node must be designed 
and tested rarefully. 



Fig. 2* A sanrplr genera] help dialog from the 1IF Help System 
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■* — The finrt topic in the sequence 
provides spec il 10 information 
about the user s context — in this 
case, a description of a control in 
the HP VUE front panel, 



Cn*l c»rnjzing Your 

l»,-Twn:ilT. -.IIm > 



-•— Since customization is an impor 
tant part of a personal toolbox, the 
sec and topic in the sequence pro- 
vides basic 'bow to" inform at ion 



k* <QDutM is: ; .tj H lajUUvA) 



- The third topic exposes some 
important related topics and 
terminology 



- The firowse button opens 8 
general help dialog. 



fpFfMMAtffrM 






l^taHl, 


_ 


i.,.!t. .!_',., M.,n. 


gfng \j4jllra1 ion* 






Fig, 3, A progressive disclosure 

seqiii-' 



Hypertext Links. The lightning speed of hypertext links, and 
their ability to jump a user baa completely different area of 
the online information, leaves most users feeling lost after 
only a few jumps. 

System designers and authors must recognize that each hy- 
pertext link is an invitation to explore, aiul therefore, also an 
invitation to get lost Most research in this area indicates that 
hyperiexi is besi used in combination with other navigation 
aids — "Hypertext is a spice, not a main course." 4 

I sability testing on the HP Help System indicates that when 
hyperlinks are used to navigate down the topic hierarchy 
other links thai span ihe hierarchy should be distinguished 
in some way, In HP MPower help, moal help volumes use a 
convention of labeling lists of "Subtopics* ami "Si e &ls0*a to 
make that distinction. 

! IP Help System provides the following features to help 
users avoid getting lost in hyperspace: 
Hack? rack command for undoing a hyperlink and going 
back bo the previous topic 

Topic hierarchy display (in the general help dialog) to show 
\t m are here" information within the current help volume 
History dialog that lists the titles of the topics recently visited 



Application Complex Application 



Ap n I i cation's Help Volume tor Help Volume lor 

Help Volume | General Users Administrators 



A "home topic" at the top of each hierarchy to give users a 
known place lo return to if they get lost. 

The Developers' Tasks 

There are many facets to developing an application with nn- 
line help. Depending on organizational structure and the size 
of the project, these (asks may lie performed by a variety of 
team members. 

Planning and Design. Planning and designing a help system 
for an applieaiion requires close collaboration between de- 
signers, authors, and programmers. Firs!, Ihe design team 
nmsl understand the user's need for the application and the 

tasks dial users will perform. From ibis information a use 
i l nidc I can be developed that describes the user's interaction 
willi i be application. 

As a user interface is designed based on the use model, every 
effort should lie made lo keep livings as obvious as possible, 
limiting ihe need for online help, Horton defines obvious as 
".. . designing products thai users already know how to 
operate ... or can learn by trying things our." ^ 



Application 



Applications 
Help Volume 



Application 



Applications 
Help Volume 



m 



I Applications 
Help Volume 



Standalone 
Help Volume 



Help Manager 



Fig, L the asso \atim >-w help volumes in applications. Mom help 

v'ljuii,,-!-, ; ,ri. ,'.-,,,i,ii< -i uirh a simple appHcation. 



Fig. 5. A help manager pj bss to ail, help volumes. 
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la) 




Help System 



lb) 





Fig, 6 , fie I p vol un te organiza I ional 1 1 » J i ■ I S ■: . i j .-\ r y | . l < ■; i i 1 1 » p 1 1 ■ 
hierarchy, (b) Hypertext Links provide shortcuts tr> span the topic 
hierarchy. (/■) An in format! mi w^k 

For every context within the application thai is not com- 
pletely obvious, identify it as an entry point into help. Assign 
a unique identifier for connecting the application context, to 
a help topic. Most help systems have an identifier naming 
scheme. In the HP Help System an identifier can be any siring 
up to 64 characters including letters, digits, and hyphens. 

Authoring. The author's job includes writing all of Ihe help 
topics, assigning (he corresponding identifiers along the 
way. For each help topic, the author must consider lire many 
ways the topic may be read. For example, a topic that is 
typically seen as an entry point (displayed directly when the 
user requests help) may also he part of the browsable topic 
hierarchy. The topic must be authored to work well in bo In 
contexts. 

The breadth and depth of exposure that an author has to the 
product during the writing process provides an opportunity 
to discover design flaws that may decrease usability. It con- 
tinues to be the author's responsibility to reduce the need 
for online help by exposing these kinds of problems 

Programming. The software developer is responsible for pro- 
viding the hooks from the software into online help. This 
requires using the agreed upon topic identifiers for displaying 
topics when the user requests help. 
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Fig. 7. Application help architectures, (a.) The traditional applica- 
tion help architecture, (b) A possible migration of the traditional 
application lielparciiil.ect.ure, (c) Another possible migration of the 

ir;ifjiiinn;il application help architecture. 

I >epending on the help system being used, there may be some 
additional programming necessary to achieve the desired 
behavior For instance, with the HP Help System, progressive 
disclosure sequences like the one shown in Fig. 8 require the 
application to provide the correct behavior for the More 
button that walks through the sequence. 

The Future of Online Help 

Much of! his paper has assumed a traditional approach to 
online help development. That is, one in which the help sys- 
tem and its Supporting information are aligned with the ap- 
plication's user interface and supporting functions. Context 
sensitivity is enable c I by direct connections between the 
help system and user interface components and states 
within the application. Fig. 7a shows a traditional applica- 
tion help architecture. 

Reference 4 describes a help system whose design is driven 
by the same knowledge base that, drives the user interface 
(via a user interface management system, or UIMS). In this 
model the flow of information and functionality is all handled 
through the I TIMS which presents the user interface for the 
application and the help system (see Fig, 7b). 

( m line Information systems of the future may evolve from 
architectures like ihe one suggested by Foley and col- 
leagues. 4 However, I expect help systems ro meld further 
into the application, to the point that the help system itself 
isn't identified as a discrete component. 

As this takes place, the engineering process Tor the informa- 
tion and knowledge portions ot products will be as important 
as the traditional hardware and software engineering tasks. In 
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fact, the information architecture will become increasingly 
difficult to distinguish from the application architecture. 

An intelligent user interface will draw upon an information 
base and the application functions to present user interface 
components (see Fig, 7c). The user interface may still present 
what the user perceives as online help, but it is generated 
from a combination of knowledge and application functions, 
along with the users current context. Further, there will he 
a strong relationship between the knowledge base and the 
application functions fa channel missing in Foley's mo«i- 

Conclusion 

Providing online help has grown in recent years from a "nit e 
to have" feature to an expected component of all significant 
application software. For some products, online heh 
duces support costs because it puts information where the 
user is more likely H> find it (meeting the goals in our goal 
hierarchy). For other products, providing online help also 
reduces tlie cost of printing hardcopy manuals. 

As applications continue to grow in complexity, so does the 
need to simplify them for users. For the foreseeable future, 
online help plays an important role in helping with that sim- 
plification. Today, online help systems are discrete compo- 
nents thai aid application developers in packaging easier 
to-use products. In the future, online help will become a 
by-product of an information engineering process that 
addresses all information aspects of a product. 
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lyn. New York, received a 
BSEE degree from North- 
eastern University in 1973, 
and completed a masters 
program in biomedical engi- 
neering from the University 
of Connecticut in 197B He 
has been with HP since 1989, when Apollo Computer 
was acquired, and is now working at the Medical 
Products Group where he develops and implements 
software for patient monitoring systems. While at 
the Apollo Division, he worked on the design, imple- 
mentation and support of Domain/OS nardcopy sub- 
systems and I/O controllers He also was the lead 
product engineer for HP SharedPrint His other pro- 
fessional experience includes working on a phased- 
array ultrasonic imaging system and a fetal heart 
monitor He's a member of the IEEE John <s married 
and has two daughters He likes woodworking and 
outdoor activities such as cross-country skiing, hiking, 
and gardening, 
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Francis P. Sung 

A software engineer at the 
Workstation Technology 
Division, Francis Sung joined 
HP in 1989, when Apollo 
Computer was acquired He 
developed portions of the 
software for the HP MPower 
fax utility and is currently 
working on support for digi- 
tal video. Earlier, he contributed to the development 
of a graphics display library and digital audio support 
He worked at Compugraphic Corporation and at Data 
General before joining Apollo. He is a member of the 
ACM and coauthor of two technical articles. Francis 
was born in Hong Kong and studied electrol engi- 
neering at Brown University, from which he received 
a BSEE degree in 1979 and an M5EE degree in 1981. 
He's married and has four children His outside inter- 
ests include fixing cars and other things around the 
house, church activities, classical music, photography, 
smgmg, and cooking 
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Mark A, Johnson 

^^^^ Mark Johnson was born in 

mk 8L Paint Pleasant, New Jersey 

^^ B and educated at the Univer- 
sity of Maine, from which he 
received a OSEE degree in 
^^ 9 19B1 He designed graphics 
hardware for CAD/CAM 
^^flj j^^^ workstations at Computer- 
^^^^™ ^P^« vision Corporation, then 
joined Apollo Computer, where he designed a gate 
array for en Apoflo graphics workstation. He joined 
HP in 1989 when Apollo was acquired. He was a 
member of tine original development team for the HP 
9000 Series 700 controllers, and worked on the archi- 
tecture, design, and implementation nf the graphical 
user interface for the HP M Power fax utility. He's eur- 
rently responsible for developing the fax software 
component for the next version of HP M Power at the 
Workstation Technology Division and is a member of 
the IEEE. Mark is married and has two daughters. 
He's active as a bicycle road racer, enjoys spending 
time with his daughters and likes mountain biking, 
cross-country skiing, and brewing hear. 

62 Audio Support in HP MPower 

Ellen Nordahl Brandt 

^m^^ A member of the technical 

^k ^ staff at the Workstation 
Technology Division. Blen 
m§-^ ., jB| Brandt received a BSEE de- 
gree from Cornell University 
in 1983, She worked on 
. \^ .ijjj B grap h ics ha rd wa re a t C om- 
I putervfsiou, then went to 
^^^^^^^^^^ Apollo Computer and joined 
HP in 1 989. when Apollo was acquired She developed 
graphics hardware for Apollo products and worked on 
the audio library for HP MPower. Ellen is married and 
has one son. 

Thomas G. Fincher 

Tarn Fincher graduated in 
1980 from Stanford Univer- 
sity with a BSEE degree and 
worked at Wang Laboratories 
and CalComp before going 
to Apollo Computer. He 
joined HP in 1989 at the 
time of Apollo's acquisition. 
His background includes 
developing graphics hardware for Apollo products 
and audio GUIs for HP MPower. He is currently a 
member of toe technical staff at HP's Workstation 
Technology DivisJon- 





MonishSShah 

Monish Shah is a graduate 
of fexas A&M University 
1BSEE 1984} and Stanford 
University (MSEE 19891 and 
an engineer/scientist at HP's 
Advanced Systems Division 
He worked on several graph- 
ics products, including HP 
SRX, HP Turbo SRX, and 
built-in graphrcs for HP 9000 Models 705 and 710 
workstations. He designed the interface ASIC for the 
audio hardware for HP MPower and is now developing 
graphics products and hardware lor HP workstations. 
His work has resulted in three patents related to 
graphics 

68 Video Support in HP MPower 

Craig S, Richard 

^^^^ Craig Richard is a member of 

m fU the technics] staff at HP's 
H M Workstation Technology 

w* 4Ph> \ Division and has been with 

HP since 1989, when Apollo 
- • 9 Computer was acquired. His 

B specialty is multimedia tech- 

nology, particularly digital 
^^^^ video. He has a BSEE degree 

[19841 from the University of Massachusetts and de- 
veloped graphics software at a startup company and 
at CalComp before joining Apollo. At Apollo, he 
worked on advanced graphics features such as multi- 
ple color maps and texture mapping. He currently de- 
velops and manages relationships with independent 
hardware and software vendors, integrating some of 
their technology into HP multimedia products. Craig 
was born in Mel rase, Massachusetts, is married, and 
has two sons. In addition to spending time with his 
family, he fikes boating, hockey, softball, skiing, and 
scuba diving, 

71 Mail Facilities in a Multimedia 
Environment 



Robert B, Williams 

A software engineer at the 

Workstation Technology 
Division, Robert Williams 
has been with HP since 
1982. He was a member af 
the development team for 
HP VUE and later worked on 
the HP MPower mail facility 
and on HP MPower system 
integration. He is currently migrating HP VUE to the 
HP-UX 10.0 operating system and working on distrib- 
uted computing issues. A member of the ACM. he's 
especially interested in user interface design in net- 
worked environments. Robert was born in Wisconsin 
and completed work for a BS degree m computer 
science from Oregon State University in 1988. His 
favorite leisure activity is sailing; he races and teaches 
a sailing class. He also enjoys mountain biking and 
gardening. 






Harry K. Phinney 

With HP since 1979, Harry 
Phinney rs a software design 
engineer at the Workstation 
Technology Division. In the 
past he provided customer 
support for calculators and 
technical support for desk 
top computers. He helped 
develop HP's first X Window 
System server and was the lead engineer for HP's 
first XI J system server More recently, he designed 
and developed software for the HP MPower mail 
facility aod text editor, Harry was born in Co rva I lis, 
Oregon and has a BS degree in mechanical engineer- 
ing from Dragon State University 1 1979). Hes married 
and enjoys brcycle racing and restoring sports cars. 

Kenneth L Steege 

i R&D software engineer Ken 
Hk St ee ge h a s been wi th HP 
1 since 1982 when he joined 
^ J t the CorvalEis Division. Im- 

tially, he was a support engi- 
j neer f o r the R Si D c a leu lato r 
lab and later developed con- 
nection management soft- 
ware for the HP Portable 
Plus He also developed XII client applications for 
the HP-UX operating system Mow a member of the 
Workstation Technology Division, he contributed to 
the development of the HP MPower mail facility and 
HP MPower integration He r s currently responsible for 
text editors for HP-UX 1 D.D Ken was born in Denver, 
Colorado and attended the University of Oregon, from 
which he received a BS degree in computer science 
in 1972. He spent ID years as a programmer/analyst 
and consultant on small IBM Corp., Digital Equipment 
Corporation, and HP business systems before corning 
to HP. He is married and has three children and four 
grandchildren He participates in a prison fellowship 
program and is involved in home schooling. Hfs other 
interests include fishing and gentleman farming. 

79 Fast and Intuitive Online Help 
System 



Michael R. Wilson 

^^^ I With HP since 1987. Mike 
^■H^m I Wilson is a member of the 
Jfl I technical staff at the Work- 

f I station Technology Division 
I Mike played an integral part 
in the development of the 
HP Help System through the 
releases of HP VUE 2.0 and 
3.0. Mike's specific responsi- 
bilities included overall system design, public appli- 
cation program interface specifications, user interface 
design and development, and custom widget creation 
He's now working on the next version of the HP Help 
System, Mike was born in Palo Alto, California and 
attended California State University at Chico. from 
which he received a BS degree in computer science 
in 1987 He is mamed and has two sons He and his 
family enjoy bicycling 
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tori A. Cook 

^^^^ _ sn Cook i s a member of the 

«*^ I technical staff at the Worx- 

^M " <*• ie joined HP m 1 980, m 
H IT I same year she completed 

J* jA I work for her 9S<ae. 

™ ^^^HH computer science from 
^^^^^E Oregon State University She 
-*"~ ^as worked on the 
storage, i/'O, and service ROMs for ttie HP &7 per- 
sonal computer, wrote ttie electron ic disk ROM for 
the HP 85 and HP 87 personal computers, and worked 
on an HP-fB driver and an HP-IB command library for 
HP personal computers Stie is current I y responsible 
for reading and rendering the text and graphics dis- 
played: \n help dialogs for the HP Help Developer's Kit. 
Lon was born in Tacoma. Washington She's married 
and her hobbies include scuba diving, skiing, reading. 
knitting, and racquetball Her newest interest is rock 
hunting 




Steven P Hie ben 

~uebert was born in 
Portland. Oregon He served 
■ in me U S . A 1 r Force for four 
I years, attaining fr-r 
' B^b|^i I staff sergeant He attended 
d State University 
from which he received a BS 
degree in mathematics in 
1978, He was a sc ■ 
engineer at Electro Scientific Industrie: 
of software engineering at TimeShare Corporation 
before joining HP in 1981 . He's currently a member of 
The technical staff at the Workstation lectin c 
Division He worked on compilers, optimizers and 
loaders for the HP Integral PC. He later developed 
shared libraries and compression techniques tor the 
executable and data files that went on the software 
engineering ROM for the HP Integral PC He has also 
done development work on servers for the X Window 
System, version 1 1 and on the HP Interface Architect. 
His work on the HP Help System included intematiun- 
ahzatian and compilation of the HP HelpTag files into 
an internal distribution format He is now working on 
the next version of the HP Help System Steve Is a 
member of the IEEE and ACM and is an author of a 
previous HP Journal article on merging Starbase 
and X1 1 



90 Developing Online Application 
Help 



Qe* Smith is a graduate of 

tl Oregon State University and 
I his a BS degree m tec 
journalism with a computer 
engineering minor *1987| 
Before joining HP in 1988. 
he was a freelance writer, 
working mostly on HP calcu- 
lator manuals As a teaming 
products engineer for the Workstation Group's user 
interface laboratory in Carvalfis, Oregon, he wrote 
the manuals for a variety of user interface products. 
including XII. OSF/Motif, and HP Interface Architect. 
He was the lead learning products engineer for the HP 
VUE 3.0 online help system, as welt as a contributor 
to the requirements assessment and design of the HP 
Help System Dex is currently an engineer/scientist 
working for HP Corporate Engineering as a company- 
wide consultant serving afl of HP's product groups in 
the areas of information engineering, user interface 
design, and multimedia technology He is a member 
of the ACM Dex and his wife have two sons 
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